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 10:27:56 -0600 Message-ID: <87ehbwsq5v.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UphjR-0005CR-Bg for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 12:29:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UphjQ-0000xy-60 for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 12:29:09 -0400 Received: from mail-pd0-f182.google.com ([209.85.192.182]:59312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UphjP-0000xs-V1 for emacs-orgmode@gnu.org; Thu, 20 Jun 2013 12:29:08 -0400 Received: by mail-pd0-f182.google.com with SMTP id r10so6418207pdi.13 for ; Thu, 20 Jun 2013 09:29:07 -0700 (PDT) In-Reply-To: <87d2rjcfsv.fsf@Rainer.invalid> (Achim Gratz's message of "Tue, 18 Jun 2013 22:41:36 +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 --=-=-= Content-Type: text/plain Achim Gratz 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. --=-=-= Content-Type: text/x-org Content-Disposition: inline; filename=header-eval-location.org * 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 --=-=-= Content-Type: text/plain > 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 --=-=-=--