From: Aaron Ecay <aaronecay@gmail.com>
To: Rainer M Krug <Rainer@krugs.de>, Rainer M Krug <r.m.krug@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, 02 Jul 2015 17:35:57 +0100 [thread overview]
Message-ID: <876162bjpu.fsf@gmail.com> (raw)
In-Reply-To: <m2pp4asovw.fsf@krugs.de>
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
next prev parent reply other threads:[~2015-07-02 16:36 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 [this message]
2015-07-02 18:21 ` Sebastien Vauban
2015-07-02 18:44 ` Rainer M Krug
2015-07-02 18:43 ` Rainer M Krug
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=876162bjpu.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=Rainer@krugs.de \
--cc=emacs-orgmode@gnu.org \
--cc=r.m.krug@gmail.com \
--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).