From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: :session question -- and changes to #+Property: syntax Date: Thu, 20 Jun 2013 12:31:53 -0600 Message-ID: <87a9mkskfa.fsf@gmail.com> 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> <874ncsad3p.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48452) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpjfN-0001qs-U9 for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 14:33:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpjfM-00034P-9m for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 14:33:05 -0400 Received: from mail-pb0-x22f.google.com ([2607:f8b0:400e:c01::22f]:64066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpjfL-00034C-W9 for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 14:33:04 -0400 Received: by mail-pb0-f47.google.com with SMTP id rr13so6520922pbb.34 for ; Thu, 20 Jun 2013 11:33:03 -0700 (PDT) In-Reply-To: <874ncsad3p.fsf@Rainer.invalid> (Achim Gratz's message of "Thu, 20 Jun 2013 19:47:22 +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: Achim Gratz Cc: emacs-orgmode@gnu.org Achim Gratz 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. > [=E2=80=A6] >>> 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. --=20 Eric Schulte http://cs.unm.edu/~eschulte