emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
To: "Charles C. Berry" <ccberry-XkckGZ689+c@public.gmane.org>
Cc: Org-Mode mailing list <emacs-orgmode-mXXj517/zsQ@public.gmane.org>
Subject: Re: How to override ":eval no" in call lines?
Date: Mon, 09 Feb 2015 15:43:55 +0100	[thread overview]
Message-ID: <86egpzjgb8.fsf@example.com> (raw)
In-Reply-To: <alpine.OSX.2.00.1501231149060.528-iDQ3frm8jJiryYnjg5slPZa4wMfmKMrbhPhL2mjWHbk@public.gmane.org> (Charles C. Berry's message of "Fri, 23 Jan 2015 11:53:20 -0800")

"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
  │ 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?

>> 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?

>> Where do <END-HEADER-ARGS> fit into that picture?
> Either before or after the :var ...
> HTH,

Not completely yet, no.

Best regards,

[1] http://orgmode.org/manual/Evaluating-code-blocks.html#Evaluating-code-blocks

Sebastien Vauban

  parent reply	other threads:[~2015-02-09 14:43 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 [this message]
2015-02-09 17:54             ` Charles C. Berry

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:

  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=86egpzjgb8.fsf@example.com \
    --to=sva-news-d0wtavr13harg/idocfnwg@public.gmane.org \
    --cc=ccberry-XkckGZ689+c@public.gmane.org \
    --cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \


* 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


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