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

[Rainer M Krug]

Envoyé de mon iPhone

> Le 2 juil. 2015 à 18:35, Aaron Ecay <address@hidden> a écrit :
> 
> 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”)

You are right - I always make this error. 

> 
>> 
>> 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.)

No - not possible with the old syntax, but I was already missing it there. And 
it would make sense to have it. 

But one was at least able to set the header argument to the default value. 

> 
>> 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.)

Cheers, 

Rainer

> 
> 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