From: Rainer M Krug <r.m.krug@gmail.com>
To: Aaron Ecay <aaronecay@gmail.com>
Cc: Sebastien Vauban <sva-news@mygooglest.com>,
"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: Tangling takes long - profiling and calling R
Date: Thu, 2 Jul 2015 20:43:04 +0200 [thread overview]
Message-ID: <B67A02A3-6722-4F64-8D24-6D4F7E16F090@gmail.com> (raw)
In-Reply-To: <876162bjpu.fsf@gmail.com>
Envoyé de mon iPhone
> Le 2 juil. 2015 à 18:35, Aaron Ecay <aaronecay@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
next prev parent reply other threads:[~2015-07-02 18:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 8:39 Tangling takes long - profiling and calling R Rainer M Krug
2015-06-15 8:42 ` Rainer M Krug
2015-06-15 18:52 ` Charles C. Berry
2015-06-16 10:29 ` Rainer M Krug
2015-06-15 19:49 ` Nicolas Goaziou
2015-06-16 10:34 ` Rainer M Krug
2015-06-16 11:46 ` Nicolas Goaziou
2015-06-16 12:45 ` Sebastien Vauban
2015-06-16 13:04 ` Nicolas Goaziou
2015-06-16 14:47 ` Rainer M Krug
2015-07-01 14:03 ` Aaron Ecay
2015-07-02 11:51 ` Nicolas Goaziou
2015-07-02 12:52 ` Rainer M Krug
2015-07-02 16:35 ` Aaron Ecay
2015-07-02 18:21 ` Sebastien Vauban
2015-07-02 18:44 ` Rainer M Krug
2015-07-02 18:43 ` Rainer M Krug [this message]
2015-07-02 16:11 ` Aaron Ecay
2015-07-03 13:43 ` Nicolas Goaziou
2015-07-02 18:51 ` Rainer M Krug
2015-06-16 14:42 ` Rainer M Krug
2015-06-16 21:45 ` Nicolas Goaziou
2015-06-17 7:16 ` org version numbers in file - WAS: " Rainer M Krug
2015-06-18 8:13 ` Nicolas Goaziou
2015-06-18 13:25 ` Rainer M Krug
2015-06-18 13:50 ` Nicolas Goaziou
2015-06-23 9:04 ` Rainer M Krug
2015-06-18 14:23 ` Detlef Steuer
2015-06-23 8:45 ` Rainer M Krug
2015-06-23 9:32 ` Detlef Steuer
2015-06-23 10:57 ` Rainer M Krug
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B67A02A3-6722-4F64-8D24-6D4F7E16F090@gmail.com \
--to=r.m.krug@gmail.com \
--cc=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=sva-news@mygooglest.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).