Envoyé de mon iPhone
> Le 2 juil. 2015 à 18:35, Aaron Ecay <aarone...@gmail.com> 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
