From: "Charles C. Berry" <ccberry@ucsd.edu>
To: Sebastien Vauban <sva-news@mygooglest.com>
Cc: Org-Mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: How to override ":eval no" in call lines?
Date: Mon, 9 Feb 2015 09:54:12 -0800 [thread overview]
Message-ID: <alpine.OSX.2.00.1502090919290.436@charles-berrys-macbook.local> (raw)
In-Reply-To: <86egpzjgb8.fsf@example.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3387 bytes --]
On Mon, 9 Feb 2015, Sebastien Vauban wrote:
> "Charles C. Berry" wrote:
>> On Fri, 23 Jan 2015, Sebastien Vauban wrote:
>>> "Charles C. Berry" wrote:
>>>> Sebastien Vauban wrote:
>>>>> In a long document, I must have ":eval no" at file level, as this
>>>>> is the common setting for most code blocks. However, how do I unset
>>>>> that for some call lines.
>>>
>>> I don't get why one has to add ":eval yes" for both types of headers
>>> arguments.
>
> I still don't get that: why do I need to add *twice* ":eval yes", in
> both the "inside header args" and the "end header args"?
>
> The documentation [1] states:
>
> ┌────
> │ END HEADER ARGUMENTS are applied to the calling instance and DO NOT
> │ AFFECT EVALUATION OF THE NAMED CODE BLOCK. They affect how the
> │ results are incorporated into the Org mode buffer and how the call
> │ line is exported.
> └────
>
> If end header args don't affect the evaluation of the name code block,
> why do we have to set ":eval" to "yes", then?
>
Because there are two evaluations to be made of a call_abc() instance or a
`#BEGIN_SRC lang :var x=abc() ...' instance:
1. one of abc()
2. one of the instance.
They can be made in any of the four combinations of `:eval yes' and `:eval
no'. See below for an example of a src block calling another using the
`:var x=abc()' idiom.
>>> Moreover, I once read that when evaluating a call line, it is
>>> converted into an ephemeral Emacs Lisp code block equivalent to the
>>> call line (and created at the point of the call line):
>>>
>>> #+begin_src emacs-lisp :var result=<NAME>(<ARGUMENTS>) <INSIDE-HEADER-ARGS>
>>> result
>>> #+end_src
>>>
>>> which is evaluated in place.
>>
>> No, like this:
>>
>> #+begin_src emacs-lisp :var result=<NAME>[<INSIDE-HEADER-ARGS>](<ARGUMENTS>)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> What's that syntax? The one described for "header arguments in function
> calls"? Aren't we recursive here: describing syntax equivalent to
> a call via the ephemeral code block, reusing syntax for a call?
>
Not sure how best to answer. Maybe try out all combos to demo what
happens:
A simple src block:
#+NAME: up
#+BEGIN_SRC emacs-lisp :var x="CbA"
(upcase x)
#+END_SRC
Eval this src block and `up' - prompted twice for evalution upon
execution. Note RESULTS == 'C B A':
#+BEGIN_SRC emacs-lisp :eval yes :var x=up[:eval yes](x="c b a")
x
#+END_SRC
#+RESULTS:
: C B A
Do not eval this src block but eval `up' - prompted to evaluate `up'
and message that evaluation is disabled appears for current src
block. No RESULTS:
#+BEGIN_SRC emacs-lisp :eval no :var x=up[:eval yes](x="c b a")
x
#+END_SRC
Eval this src block and not `up' - prompted once for evaluation. Note
RESULTS == 'nil', as x did not get a value assigned to it:
#+BEGIN_SRC emacs-lisp :eval yes :var x=up[:eval no](x="c b a")
x
#+END_SRC
#+RESULTS:
: nil
Eval neither. No prompts. No result.
#+BEGIN_SRC emacs-lisp :eval no :var x=up[:eval no](x="c b a")
x
#+END_SRC
>>> Where do <END-HEADER-ARGS> fit into that picture?
>>
>> Either before or after the :var ...
>>
Maybe better to say:
In this context the equivalent of <END-HEADER-ARGS> is the `:eval'
header for the src block, which can go anywhere on the line. The
<END-HEADER-ARGS> if supplied in this context seem to be ignored.
HTH,
Chuck
prev parent reply other threads:[~2015-02-09 17:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-15 14:55 How to override ":eval no" in call lines? Sebastien Vauban
2015-01-22 8:28 ` Sebastien Vauban
2015-01-22 16:50 ` Charles C. Berry
2015-01-23 11:44 ` Sebastien Vauban
2015-01-23 19:53 ` Charles C. Berry
[not found] ` <alpine.OSX.2.00.1501231149060.528-iDQ3frm8jJiryYnjg5slPZa4wMfmKMrbhPhL2mjWHbk@public.gmane.org>
2015-02-09 14:43 ` Sebastien Vauban
2015-02-09 17:54 ` Charles C. Berry [this message]
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=alpine.OSX.2.00.1502090919290.436@charles-berrys-macbook.local \
--to=ccberry@ucsd.edu \
--cc=emacs-orgmode@gnu.org \
--cc=sva-news@mygooglest.com \
/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).