[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [babel] :eval and #+call lines

From: Aaron Ecay
Subject: Re: [O] [babel] :eval and #+call lines
Date: Wed, 04 Nov 2015 14:58:30 +0000
User-agent: Notmuch/0.20.2+65~gbd5504e (http://notmuchmail.org) Emacs/ (x86_64-unknown-linux-gnu)

Hi Andreas,

2015ko urriak 29an, Andreas Leha-ek idatzi zuen:
> Hi all,
> Since this is not related to caching, I post this as a separate question
> from [1].

Thanks for the report.

> I want to argue that specifying ':eval never' as argument to a #+call
> line should transitively apply to the called block as well.

I’m not sure what we should do here.  The system of inner and outer
header args is consistent, even when it leads to strange results as in
this case.  I would hesitate to introduce special cases to the system.

A better option would be to fix the system in general.  Ideally we would
not need both sets of header arguments.  Currently, for evaluating:

#+call: foo[:inner args](bar="baz") :outer args

babel in effect evaluates this dummy elisp code block:

#+begin_src emacs-lisp :var results=foo(bar="baz")

Resolving the :var reference causes the block named foo to be evaluated.
The inner args go to the foo block, and the outer args are added to the
dummy elisp block.  It would be better (less confusing) if there were no
need to evaluate the dummy elisp block.  Rather, foo should be evaluated
and its result inserted directly (somehow...).

This change is not straightforward though.  It also has backwards
compatibility implications (what to do with the header args when both
sets are given).  And it interacts with the behavior of :cache, as
you’ve pointed out in the other thread.

Certainly a warning could be put in the manual about this case (patches

Aaron Ecay

reply via email to

[Prev in Thread] Current Thread [Next in Thread]