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
