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

[Eric Schulte <schulte.eric@gmail.com>]

Achim Gratz <Stromeko@nexgo.de> writes:

> 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.
>

Oh, I understand now.  I would also be happy with using *no* header
arguments for this ephemeral elisp block if that is easily accomplished.

>
>
>>> 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.
>

I agree.  This sounds like it would probably be overkill.

>
>>> 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.
>

Agreed.

>
>>> 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.
>

Hopefully the simpler solution which uses the existing value of
`org-babel-current-src-block-location' will prove sufficient (once
someone implements it that is...).

Cheers,

>
>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte