Re: [O] Tangling takes long - profiling and calling R

[Aaron Ecay]

Hi Rainer,

2015ko uztailak 2an, Rainer M Krug-ek idatzi zuen:

> What I am missing in the new syntax is the possibility to *change* the
> value of one header argument or to *remove* one.
> 
> There is
> 
> ,----
> | :header-args: tangle testfile.R
> `----

(Nit: I think all your examples are missing an additional colon before
the header arg name, so the above should be “:header-args: :tangle testfile.R”)

> 
> Which sets the property header-args, there is
> 
> ,----
> | :header-args+: noweb yes
> `----
> 
> which adds to header-args, what is missing is
> 
> ,----
> | :header-args-: noweb
> `----
> 
> which would remove the "noweb yes" from the header arguments 

This is not possible with the old syntax either, though:

* One
:PROPERTIES:
:noweb: yes
:END:

** Two
:PROPERTIES:
???????
:END:

#+begin_src emacs-lisp
  ...
#+end_src

There’s nothing you can put in the ?s at heading Two to get rid of the
noweb property inherited from One.  (Unless you have something in mind
which I’m not thinking of.)

> and possibly
> 
> ,----
> | :header-args-+: noweb exec
> `----
> 
> which would *replace* the "noweb yes" with "noweb exec", so it is
> effectively identical to
> 
> ,----
> | :header-args-: noweb
> | :header-args+: noweb exec
> `----
>

OTOH this is a real difference.  It corresponds in the old system to

* One
:PROPERTIES:
:noweb: yes
:END:

** Two
:PROPERTIES:
:noweb: exec
:END:

#+begin_src emacs-lisp
  ... ;; noweb=exec
#+end_src

** Three

#+begin_src emacs-lisp
  ... ;; noweb=yes
#+end_src


> 
> I know this might be difficult as header-args is simply a string, 

This is precisely the issue: this would require extending properties to
allow them to be used/interpreted as string-plists, instead of merely
strings as they presently are.  It would necessitate changing or adding
lots of functions related to the property API.  Then you have header
args like “:results” which can take multiple words.  Do we want to
support something like the following (from the old system), which would
require even more changes on top of properties-as-plist-strings in the
new one:

* One
:PROPERTIES:
:results: output
:END:

** Two
:PROPERTIES:
:results+: table
:END:

#+begin_src emacs-lisp
  ... ;; results = output table
#+end_src

** Three

:PROPERTIES:
:results+: list
:END:

#+begin_src emacs-lisp
  ... ;; results = output list
#+end_src

(AFAIK even whether property+ prepends or appends to the property value
as a string is not defined, which is already a potential issue though
not one that crops up for babel which is order-insensitive.)

Aaron

PS I am aware that all the examples I quoted are uninteresting in the
context of a single source block, which could just use header arguments.
Consider a large library of babel organized, taking the last example I
constructed, like:

* Blocks with interesting output
** Blocks which output interesting tables
<a dozen blocks>
** Blocks which output interesting lists
<another dozen>

PPS Under either system there’s the issue of the :post header arg, which
composes in a non-concatenative way.  You might have:

* Things which should be wrapped in delimiters
:PROPERTIES:
:post: wrap-delims(*this*)
:END:

** Things which should be in red text
:PROPERTIES:
:post: make-red(*this*)
:END:

#+begin_src emacs-lisp
  ;; produce a result which should be delimited and red
#+end_src

The result we want is for :post to read wrap-delims(make-red(*this*))
or make-red(wrap-delims(*this*)), depending on our opinion of red
delimiters.  But post is very brittle in any case, so this problem isn’t
very important.

-- 
Aaron Ecay