From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: :session question -- and changes to #+Property: syntax
Date: Thu, 20 Jun 2013 19:47:22 +0200 [thread overview]
Message-ID: <874ncsad3p.fsf@Rainer.invalid> (raw)
In-Reply-To: 87ehbwsq5v.fsf@gmail.com
Eric Schulte writes:
>> 2. The evaluation of header arguments assumes emacs-lisp as a language.
>
> Yes, if one wants to execute a language other than Emacs-Lisp, then they
> should use a full fledged code block and pass a reference to that code
> block into the header argument.
[…]
>> For the second, I think that "lob" should be treated as a language for
>> the purpose of anything *-default-header-args* so these settings can be
>> independently controlled.
>
> I don't know what this means. I'm either mis-understanding your second
> issue, or I strongly disagree with it. I do not think it should be
> possible to embed arbitrary language source code into header arguments.
I'm talking about the ephemeral source block that org-babel-lob-execute
constructs. This is an emacs-lisp block and I see indeed no use of
using a different language there, but I don't think it should
necessarily use the default header arguments for all other emacs-lisp
blocks. If these header arguments must be changeable, rather than
simply fixed, my suggestion is to use org-babel-default-header-args:lob
for that (and the moral equivalent for properties) so that setting some
strange default haeder args for elisp blocks doesn't inadvertently take
out LOB calls.
>> These two combined make it somewhat difficult to use properties to
>> control the behaviour of LOB calls and understand what is happening and
>> why. A workaround is to beam the source to the place of call via noweb
>> syntax.
>
> This seem a little Rube Goldberg'ish to me.
That's actually a somewhat natural looking construct in Babel; certainly
not the most elegant, but it gets the job done.
> I think the best way to handle the first issue would be to use the
> recently introduced `org-babel-current-src-block-location' variable, and
> jump back to that location when evaluation header arguments.
I still have to convince myself that this works for this purpose, but
yes, that'd be the most obvious solution if the properties should only
be evaluated from the site of call. If anything, the resulting
behaviour for nested Babel calls is more difficult to explain than what
we have now however.
>> Another thorny question is how to deal with another layer of calls
>> that might evaluate properties again.
>
> If this is something we need to support, then we would want to turn the
> `org-babel-current-src-block-location' variable into a list onto which
> we push and pop locations. Presumably it would then be possible to
> evaluate each header argument at the correct location.
That may not be as easy as you make it sound in the above sentence.
Anyway, if we had such a (hypothetical) facility, I'm not sure if the
additional control over the execution produces a net benefit over the
increased complexity.
>> A last option would be to introduce another header argument that can
>> be used to inject the properties into the argument list of the call
>> and, if set, would suppress any property evaluation in downstream
>> calls.
>
> I'm not sure I fully understand this solution.
Since it is another hypothetical solution, I'm not sure yet either. The
idea is to record only the original call site in
org-babel-current-src-block-location and hand (probably a list of)
additional call sites or properties evaluated at those sites over to the
source block as a header argument. This would have the benefit that the
called function might be able to decide what to do with those, in
particular overwrite or delete it. This allows yet more control, but
see above.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
next prev parent reply other threads:[~2013-06-20 17:47 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 9:37 :session question Andreas Röhler
2013-03-25 23:58 ` Michael Gauland
2013-03-26 0:46 ` Eric Schulte
2013-03-26 8:37 ` Andreas Röhler
2013-03-26 9:12 ` Rainer M Krug
2013-03-26 9:23 ` Andreas Leha
2013-03-26 12:37 ` Eric Schulte
2013-03-26 12:44 ` Andreas Leha
2013-03-26 12:55 ` Achim Gratz
2013-03-26 15:31 ` Eric Schulte
2013-03-27 8:01 ` :session question - header argument setting Rainer M Krug
2013-03-27 8:35 ` Sebastien Vauban
2013-03-27 8:52 ` :session question Andreas Röhler
2013-03-27 9:27 ` Andreas Leha
2013-03-27 11:37 ` Andreas Röhler
2013-03-27 11:48 ` Nick Dokos
2013-03-27 12:18 ` Andreas Röhler
2013-03-27 12:22 ` Rainer M Krug
2013-03-27 12:47 ` Andreas Röhler
2013-03-27 12:43 ` Eric Schulte
2013-03-27 13:26 ` Andreas Röhler
2013-03-27 13:29 ` Andreas Leha
2013-03-27 15:47 ` Eric Schulte
2013-03-27 20:20 ` Andreas Leha
2013-03-27 20:35 ` Eric Schulte
2013-03-28 10:25 ` Andreas Leha
2013-03-28 13:06 ` John Hendy
2013-03-28 19:35 ` :session question - a simple PATCH Andreas Leha
2013-03-29 9:59 ` Achim Gratz
2013-03-29 14:38 ` Eric Schulte
2013-03-28 13:22 ` :session question John Hendy
2013-03-27 20:59 ` Andreas Röhler
2013-03-27 11:19 ` Andreas Leha
2013-04-28 15:46 ` Achim Gratz
2013-05-01 17:18 ` Eric Schulte
2013-05-01 17:36 ` Achim Gratz
2013-05-09 18:52 ` Achim Gratz
2013-06-07 16:15 ` Achim Gratz
2013-06-07 19:07 ` :session question -- and changes to #+Property: syntax Eric Schulte
2013-06-07 19:49 ` Achim Gratz
2013-06-07 20:22 ` Andreas Leha
2013-06-10 8:16 ` Rainer M Krug
2013-06-08 7:47 ` Achim Gratz
2013-06-08 18:08 ` Eric Schulte
2013-06-08 20:48 ` Achim Gratz
2013-06-10 8:21 ` Rainer M Krug
2013-06-10 19:16 ` Achim Gratz
2013-06-18 20:41 ` Achim Gratz
2013-06-19 10:10 ` Michael Brand
2013-06-20 16:27 ` Eric Schulte
2013-06-20 17:47 ` Achim Gratz [this message]
2013-06-20 18:31 ` Eric Schulte
2013-06-20 19:14 ` Achim Gratz
2013-06-20 19:28 ` Eric Schulte
2013-06-23 17:50 ` Achim Gratz
2013-06-25 14:20 ` Eric Schulte
2013-06-25 18:28 ` Achim Gratz
2013-06-10 8:14 ` :session question Rainer M Krug
2013-06-10 8:12 ` Rainer M Krug
2013-03-27 8:26 ` Andreas Röhler
2013-03-26 6:41 ` Andreas Röhler
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=874ncsad3p.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/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).