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

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

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Achim Gratz <Stromeko@nexgo.de> writes:

> Hi Eric,
>
> while starting to write up a test document I've found some behaviour
> when executing LOB calls that warrant discussion, I think:
>
> 1. The properties are evaluated at the site of the definition rather
>    than the site of the call.

I see what you're saying.  The attached org-mode file demonstrates.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: header-eval-location.org --]
[-- Type: text/x-org, Size: 363 bytes --]

* first
  :PROPERTIES:
  :CUSTOM_ID: first
  :END:

#+name: heading-id
#+begin_src emacs-lisp :var point=(point)
  (format "%s at %d" (org-entry-get point "CUSTOM_ID") point)
#+end_src

#+RESULTS: heading-id
: first at 53

* second
  :PROPERTIES:
  :CUSTOM_ID: second
  :END:

#+call: heading-id(point=(point))

#+RESULTS: heading-id(point=(point))
: first at 53

[-- Attachment #3: Type: text/plain, Size: 2232 bytes --]


> This is simply how org-babel-process-params works, it jumps to the
> definition and then executes the source block there (this may be in
> another file even).
>
> 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.

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

> The first point could perhaps be addressed in a cleaner way by using
> org-babel-current-src-block-location when calling org-entry-get, but
> I'm not sure yet if it is always correctly set.

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.

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

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

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

Cheers,

>
>
> Thoughts, comments?
>
>
> Regards,
> Achim.

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