From: Aaron Ecay <aaronecay@gmail.com>
To: Achim Gratz <Stromeko@nexgo.de>, emacs-orgmode@gnu.org
Subject: Re: Difference :header-args: and :header-args+:?
Date: Wed, 17 Sep 2014 21:37:36 -0400 [thread overview]
Message-ID: <87sijpr9nj.fsf@gmail.com> (raw)
In-Reply-To: <87fvg07vzi.fsf@Rainer.invalid>
Hi Achim,
2014ko irailak 9an, Achim Gratz-ek idatzi zuen:
>
> 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.
Surely the point of call is just where they are written in the buffer?
In any case, I’ll just take your word for it that there are unspecified
difficulties.
[...]
>> 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 one point of view. The other is that you should be able to
specify a babel block’s 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.
But this issue is orthogonal to how the default headers are calculated,
isn’t it?
[...]
>
> 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.
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’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.
Sorry, I still don’t get it. I guess this is just a wart of the
interaction between the two systems; let’s hope it disappears as soon as
possible.
--
Aaron Ecay
next prev parent reply other threads:[~2014-09-18 1:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 10:52 Difference :header-args: and :header-args+:? Rainer M Krug
2014-09-04 16:36 ` Aaron Ecay
2014-09-05 7:30 ` Rainer M Krug
2014-09-06 1:18 ` Aaron Ecay
2014-09-08 10:36 ` Rainer M Krug
2014-09-08 14:27 ` Achim Gratz
2014-09-08 22:05 ` Aaron Ecay
2014-09-09 8:20 ` Rainer M Krug
2014-09-09 13:57 ` Achim Gratz
2014-09-09 19:19 ` Rainer M Krug
2014-09-09 13:40 ` Achim Gratz
2014-09-18 1:37 ` Aaron Ecay [this message]
2014-09-09 7:40 ` Rainer M Krug
2014-09-09 7:56 ` Rainer M Krug
2014-09-08 14:17 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sijpr9nj.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=Stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).