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