From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Difference :header-args: and :header-args+:? Date: Wed, 17 Sep 2014 21:37:36 -0400 Message-ID: <87sijpr9nj.fsf@gmail.com> References: <877g1j1gwx.fsf@gmail.com> <87vbp1r1fk.fsf@gmail.com> <87sik29ogv.fsf@Rainer.invalid> <87r3zlrcnt.fsf@gmail.com> <87fvg07vzi.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]:35025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUQfR-00056z-DV for emacs-orgmode@gnu.org; Wed, 17 Sep 2014 21:38:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUQfI-0008L4-Bv for emacs-orgmode@gnu.org; Wed, 17 Sep 2014 21:37:53 -0400 Received: from mail-qc0-x22e.google.com ([2607:f8b0:400d:c01::22e]:62742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUQfI-0008KY-70 for emacs-orgmode@gnu.org; Wed, 17 Sep 2014 21:37:44 -0400 Received: by mail-qc0-f174.google.com with SMTP id m20so286082qcx.33 for ; Wed, 17 Sep 2014 18:37:38 -0700 (PDT) In-Reply-To: <87fvg07vzi.fsf@Rainer.invalid> 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 , emacs-orgmode@gnu.org Hi Achim, 2014ko irailak 9an, Achim Gratz-ek idatzi zuen: >=20 > Aaron Ecay writes: >> Can you say more about the corner cases? >=20 > 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. Surely the point of call is just where they are written in the buffer? In any case, I=E2=80=99ll just take your word for it that there are unspeci= fied difficulties. [...] >> Most computer languages with which I=E2=80=99m 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. >=20 > 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.=20=20 That=E2=80=99s one point of view. The other is that you should be able to specify a babel block=E2=80=99s behavior fully (i.e. including header args)= and know that it will have that behavior no matter where it is called from. I think this system better promotes writing modular babel documents. > That's also important for caching since the cache signature for results > doesn't take default headers into account.=20=20 But this issue is orthogonal to how the default headers are calculated, isn=E2=80=99t it? [...] >=20 > 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. >=20 > 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. OK, I see. With this bug fixed, the new system probably has similar power to the old one indeed. (Modulo the point of definition vs. point of call issue.) [...] >> It looks like it is trying to demonstrate >> inheritance and overriding of :var header args. I can=E2=80=99t figure = out >> why the #+call in =E2=80=9COverwrite=E2=80=9D gets go1, but the addition= of =E2=80=9Cvar+ to1=E2=80=9D >> in =E2=80=9CAccumulate=E2=80=9D causes this to shift, not to =E2=80=9Cto= 1=E2=80=9D, but to =E2=80=9Cge1=E2=80=9D. >=20 > 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=3D"th3" definition to see this in action. Sorry, I still don=E2=80=99t get it. I guess this is just a wart of the interaction between the two systems; let=E2=80=99s hope it disappears as so= on as possible. --=20 Aaron Ecay