From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: Tangling takes long - profiling and calling R Date: Thu, 2 Jul 2015 20:43:04 +0200 Message-ID: References: <87ioaobvl1.fsf@selenimh.access.network> <87a8vzc1u8.fsf@selenimh.access.network> <07F390A6-B112-4E02-8417-E9280B24AC94@gmail.com> <87zj3gj7qg.fsf@gmail.com> <87h9pmn5fh.fsf@nicolasgoaziou.fr> <876162bjpu.fsf@gmail.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAjS6-00070g-31 for emacs-orgmode@gnu.org; Thu, 02 Jul 2015 14:43:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAjS2-0002oj-Sf for emacs-orgmode@gnu.org; Thu, 02 Jul 2015 14:43:14 -0400 Received: from mail-wg0-x22e.google.com ([2a00:1450:400c:c00::22e]:33224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAjS2-0002oW-Gx for emacs-orgmode@gnu.org; Thu, 02 Jul 2015 14:43:10 -0400 Received: by wgck11 with SMTP id k11so70625810wgc.0 for ; Thu, 02 Jul 2015 11:43:09 -0700 (PDT) In-Reply-To: <876162bjpu.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Aaron Ecay Cc: Sebastien Vauban , "emacs-orgmode@gnu.org" Envoy=C3=A9 de mon iPhone > Le 2 juil. 2015 =C3=A0 18:35, Aaron Ecay a =C3=A9cri= t : >=20 > Hi Rainer, >=20 > 2015ko uztailak 2an, Rainer M Krug-ek idatzi zuen: >=20 >> What I am missing in the new syntax is the possibility to *change* the >> value of one header argument or to *remove* one. >>=20 >> There is >>=20 >> ,---- >> | :header-args: tangle testfile.R >> `---- >=20 > (Nit: I think all your examples are missing an additional colon before > the header arg name, so the above should be =E2=80=9C:header-args: :tangle= testfile.R=E2=80=9D) You are right - I always make this error.=20 >=20 >>=20 >> Which sets the property header-args, there is >>=20 >> ,---- >> | :header-args+: noweb yes >> `---- >>=20 >> which adds to header-args, what is missing is >>=20 >> ,---- >> | :header-args-: noweb >> `---- >>=20 >> which would remove the "noweb yes" from the header arguments >=20 > This is not possible with the old syntax either, though: >=20 > * One > :PROPERTIES: > :noweb: yes > :END: >=20 > ** Two > :PROPERTIES: > ??????? > :END: >=20 > #+begin_src emacs-lisp > ... > #+end_src >=20 > There=E2=80=99s 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=E2=80=99m not thinking of.) No - not possible with the old syntax, but I was already missing it there. A= nd it would make sense to have it.=20 But one was at least able to set the header argument to the default value.=20= >=20 >> and possibly >>=20 >> ,---- >> | :header-args-+: noweb exec >> `---- >>=20 >> which would *replace* the "noweb yes" with "noweb exec", so it is >> effectively identical to >>=20 >> ,---- >> | :header-args-: noweb >> | :header-args+: noweb exec >> `---- >=20 > OTOH this is a real difference. It corresponds in the old system to >=20 > * One > :PROPERTIES: > :noweb: yes > :END: >=20 > ** Two > :PROPERTIES: > :noweb: exec > :END: >=20 > #+begin_src emacs-lisp > ... ;; noweb=3Dexec > #+end_src >=20 > ** Three >=20 > #+begin_src emacs-lisp > ... ;; noweb=3Dyes > #+end_src >=20 >=20 >>=20 >> I know this might be difficult as header-args is simply a string, >=20 > 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 =E2=80=9C:results=E2=80=9D 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: >=20 > * One > :PROPERTIES: > :results: output > :END: >=20 > ** Two > :PROPERTIES: > :results+: table > :END: >=20 > #+begin_src emacs-lisp > ... ;; results =3D output table > #+end_src >=20 > ** Three >=20 > :PROPERTIES: > :results+: list > :END: >=20 > #+begin_src emacs-lisp > ... ;; results =3D output list > #+end_src >=20 > (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,=20 Rainer >=20 > Aaron >=20 > 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: >=20 > * Blocks with interesting output > ** Blocks which output interesting tables > > ** Blocks which output interesting lists > >=20 > PPS Under either system there=E2=80=99s the issue of the :post header arg,= which > composes in a non-concatenative way. You might have: >=20 > * Things which should be wrapped in delimiters > :PROPERTIES: > :post: wrap-delims(*this*) > :END: >=20 > ** Things which should be in red text > :PROPERTIES: > :post: make-red(*this*) > :END: >=20 > #+begin_src emacs-lisp > ;; produce a result which should be delimited and red > #+end_src >=20 > 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=E2=80= =99t > very important. >=20 > --=20 > Aaron Ecay