Achim Gratz <strom...@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.
* 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
> 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
