Re: :session question -- and changes to #+Property: syntax

[Achim Gratz <Stromeko@nexgo.de>]

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