[babel] :eval and #+call lines

[babel] :eval and #+call lines

[Andreas Leha]

Hi all,

Since this is not related to caching, I post this as a separate question
from [1].

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

Here is the example:

--8<---------------cut here---------------start------------->8---
* Test
** A long running code block.
#+name: foo
#+begin_src emacs-lisp :var bar="baz"
  (sit-for 15)
  (message "bar=%S" bar)
#+end_src

** Calling

This should not execute anything IMO.
#+call: foo("qux") :eval never

I.e. it should behave as this:
#+call: foo[:eval never]("qux") :eval never
--8<---------------cut here---------------end--------------->8---

Regards,
Andreas



[1] http://permalink.gmane.org/gmane.emacs.orgmode/102349

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

[Aaron Ecay]

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")
  results
#+end_src

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
welcome...)

-- 
Aaron Ecay