From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: :session question -- and changes to #+Property: syntax Date: Thu, 20 Jun 2013 19:47:22 +0200 Message-ID: <874ncsad3p.fsf@Rainer.invalid> References: <51501AF2.1070405@easy-emacs.de> <8738vjugwd.fsf@gmail.com> <51516699.6090604@gmail.com> <87ip4ezf93.fsf@med.uni-goettingen.de> <87fvzi72ve.fsf@gmail.com> <87ip4e5gai.fsf@gmail.com> <87k3nmd5es.fsf@Rainer.invalid> <87sj264o0f.fsf@gmail.com> <87k3n8gf47.fsf@Rainer.invalid> <878v2l7v7s.fsf@Rainer.invalid> <87txl9u4c4.fsf_-_@gmail.com> <87d2rjcfsv.fsf@Rainer.invalid> <87ehbwsq5v.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpixP-0007Jv-Va for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 13:47:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpixN-0002To-Hz for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 13:47:39 -0400 Received: from plane.gmane.org ([80.91.229.3]:51179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpixN-0002TS-Ah for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 13:47:37 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UpixL-0002zE-MK for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 19:47:35 +0200 Received: from pd9eb0e17.dip0.t-ipconnect.de ([217.235.14.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Jun 2013 19:47:35 +0200 Received: from Stromeko by pd9eb0e17.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Jun 2013 19:47:35 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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