From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: Difference :header-args: and :header-args+:? Date: Tue, 09 Sep 2014 15:40:33 +0200 Message-ID: <87fvg07vzi.fsf@Rainer.invalid> References: <877g1j1gwx.fsf@gmail.com> <87vbp1r1fk.fsf@gmail.com> <87sik29ogv.fsf@Rainer.invalid> <87r3zlrcnt.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]:44834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRLfF-0000C3-0U for emacs-orgmode@gnu.org; Tue, 09 Sep 2014 09:41:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XRLf9-0006FG-6G for emacs-orgmode@gnu.org; Tue, 09 Sep 2014 09:40:56 -0400 Received: from plane.gmane.org ([80.91.229.3]:49820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRLf8-0006FC-SL for emacs-orgmode@gnu.org; Tue, 09 Sep 2014 09:40:51 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XRLf7-0005pk-F2 for emacs-orgmode@gnu.org; Tue, 09 Sep 2014 15:40:49 +0200 Received: from pd9eb003e.dip0.t-ipconnect.de ([217.235.0.62]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Sep 2014 15:40:49 +0200 Received: from Stromeko by pd9eb003e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Sep 2014 15:40:49 +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 Aaron Ecay writes: > Can you say more about the corner cases? It's been quite some time since I looked at this, but inline calls were quirky for instance since their point of call is ill-defined. > As to the non-scalability, that should be fixed by some combination of > the parser cache and retrieving all properties at once (via > ‘org-entry-properties’) rather than ‘org-entry-get’-ing them > one-by-one. I don't think that will solve the problems. Note that the new syntax is dealing with default header args via the property facility just the same and the only real change is that it makes it possible to separate different Babel languages as well as defaults for all languages. > Most computer languages with which I’m familiar (Python, R, > C, Scheme/Lisp, ...) use lexical scoping by default, and elisp has been > slowly but steadily moving in that direction for years. Thus this new > suggested dynamic-type behavior for header args is surprising to me. There isn't even an execution model for Babel, so this discussion is going nowhere. Anyway, the idea was that when you look at a Babel invocation, you should be able to figure out the default header args at that point without actually having to trace the execution all the way down to the last recursion level. That's also important for caching since the cache signature for results doesn't take default headers into account. If you want to fix header args for certain block you can already do so by just specifying the header arg directly with the surce block. If you absolutely must use properties for this, you can simply do something like :var test=(org-entry-get nil "property" 'inherit) to pick up a property at the site of definition. But then at least it is explicit. > The first demonstration in the attachment (not related to #+calls) > seems like a much clearer case of deficiency of the new system: an > inability to inherit different args from different levels. No, it doesn't demonstrate this. Try to accumulate something to the commenr property via comment+ at the lower level and convince yourself it fails in exactly the same way: only the lowest level is returned as the value of the property. That looks like a bug in the property API. When getting the property it determines that the property is defined at the lowest level and then doesn't ascend into the upper ones. But even the examples in the manual show that the entry should add to the higher level definition of the property if the +-variant is used. The problem is that org-entry-get-with-inheritance uses org-entry-get (with the inheritance parameter set to nil), but has no provision to check for the "+" on the property. >> /testing/examples/ob-header-arg-defaults.org > > I find the content of this file incredibly dense, and the suggestion > of its use as documentation bordering on a joke. I wasn't offering it as documentation, only as a means to figure out what is or isn't supposed to be working. Plus it does boil down the whole topic into the smallest possible space. And if you do that you'll see that inheritance across multiple levels has not been tested so far (also not all possible combinations of shadowing), only inheritance between global and tree properties. > (Documentation may > not exist, and that just means an area for improvement has been found. > But it’s not as though we’re all going to read that file and suddenly > understand what you mean.) It looks like it is trying to demonstrate > inheritance and overriding of :var header args. I can’t figure out > why the #+call in “Overwrite” gets go1, but the addition of “var+ to1” > in “Accumulate” causes this to shift, not to “to1”, but to “ge1”. The most specific layer is ge1. While go1 is shadowed by to1 in the same layer, this is then again shadowed by ge1 (the more specific layer). Shadowing only happens in the same layer, which are overlaid only just before the invocation. Add :var+: "to3" and remove the t3="th3" definition to see this in action. > That is a very confusing interaction (to name just one). It’s also not > clear to me how it relates to other header args, since vars supplement > each other, whereas other types of header replace. The other header args are treated exactly the same, it's just that whatever their latest definition "wins" and you never see the other definitions. Properties are just strings right until babel interprets them as header args. If you print the complete properties as they get seen by the source block, you'll see this. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada