From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: :session question -- and changes to #+Property: syntax Date: Tue, 18 Jun 2013 22:41:36 +0200 Message-ID: <87d2rjcfsv.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Up2iu-0000zP-CQ for emacs-orgmode@gnu.org; Tue, 18 Jun 2013 16:41:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Up2it-0007w1-Ew for emacs-orgmode@gnu.org; Tue, 18 Jun 2013 16:41:52 -0400 Received: from plane.gmane.org ([80.91.229.3]:38886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Up2it-0007vr-9M for emacs-orgmode@gnu.org; Tue, 18 Jun 2013 16:41:51 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Up2ip-0003pj-NU for emacs-orgmode@gnu.org; Tue, 18 Jun 2013 22:41:47 +0200 Received: from pd9eb4413.dip0.t-ipconnect.de ([217.235.68.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Jun 2013 22:41:47 +0200 Received: from Stromeko by pd9eb4413.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Jun 2013 22:41:47 +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 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. 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. 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. 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. Another thorny question is how to deal with another layer of calls that might evaluate properties again. 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. 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. Thoughts, comments? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada