From: "Charles C. Berry" <ccberry@ucsd.edu>
To: John Hendy <jw.hendy@gmail.com>
Cc: Nick Dokos <ndokos@gmail.com>, emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: exporting documents w/ babel results w/o evaluating babel blocks
Date: Sun, 22 May 2016 14:52:45 -0700 [thread overview]
Message-ID: <alpine.OSX.2.20.1605221317160.813@charles-berrys-macbook.local> (raw)
In-Reply-To: <CA+M2ft8EpVA8zV5oAGrOjV4D2QjwO5=gagmpnQboLPD015Z-vA@mail.gmail.com>
John and Nick,
Comments in line below.
TL;DR: Org babel headers give excellent control over what gets run,
when it gets run, and how. Users should use them. Don't reset
`org-export-babel-evaluate'.
Chuck
On Sun, 22 May 2016, John Hendy wrote:
> On Fri, May 20, 2016 at 4:20 PM, Charles C. Berry <ccberry@ucsd.edu> wrote:
>> On Fri, 20 May 2016, Nick Dokos wrote:
>>
>>> Ken Mankoff <mankoff@gmail.com> writes:
>>>
>> [deleted discussion of `org-export-babel-evaluate' settings]
>>
>>>
>>> With ":exports results" and o-e-b-e set to nil, I get no evaluation on
>>> export, but I get both code and results in the output.
>>>
>>>> There may have been a misunderstanding, but when I mentioned this in
>>>> the bug report, I was told this is a "feature".
>>>>
>>>> http://thread.gmane.org/gmane.emacs.orgmode/107230/focus=107231
>>>>
>>>
>>> Not sure what exactly Chuck meant is a feature, but IIUC, the fact
>>> that I get both code and results even if I specify ":exports results"
>>> looks like a bug to me.
>>>
>>
>> I meant this, as of commit ec615b1..., `org-export-babel-evaluate' set to
>> `nil' keeps the exporter from running this line
>>
>> (org-export-execute-babel-code)
>>
>> during exports. So, 'no Babel code is run' in the sense that the above
>> line does not execute.
>>
>> src-blocks and inline-src-blocks are neither run nor removed, and no
>> #+results:<etc> or {{{results()}}} are added, removed, or
>> modified. Babel handles all that. The exporter merely formats those
>> things once Babel is done.
>>
>> So the bug, if any, is in the docstring in failing to mention that
>> everything that babel does is switched off.
>
> I don't entirely follow. Is there an intermediate step between a .org
> src block, babel, and the exporter? If so, the behavior I see could
> make sense. If not, then it doesn't.
>
> As in, why is babel "execution" (as in o-e-b-e to non-nil) required to
> *not* export this code into the resultant pdf?
>
> #+begin_src R :exports results :results output
> dat <- 1:10
> print(dat)
> #+end_src
>
> With o-e-b-e set to nil, I get the code in the exported document,
> hence my asking. If I turn o-e-b-e on, I don't (but get the results).
> So perhaps the real missing bit from the documentation is something
> like "all babel functionality is turned off, and babel is responsible
> for executing code and generating/updating any results, as well as
> controlling src block export controls (results vs. code vs. both). In
> other words, without babel, src blocks in .org files are treated like
> example blocks during export."
>
> Is that accurate?
>
Yes. That is the point. Babel does it all.
(Caveat: 'like example blocks' is not precisely true, since the
exporter calls a src-block transcoder for the formatting.)
> I think one of the main points of confusion in this thread still has
> to do with why o-e-b-e switches what gets exported. If no code/results
> are run/added/removed/modified as you mention, it doesn't speak to why
> code export is always done for o-e-b-e = nil, but not otherwise. This
> suggests babel is doing more than "executing code;" it's somehow
> influencing what makes it into the export document. At least for me,
> that was an unexpected interpretation of "everything babel does is
> switched off."
Babel is a fairly complicated beast.
If you want to grok what it is doing during export, you could instrument
`org-export-as' (do `(info "(elisp) Edebug")' if you need to know about
this), export something with babel code in it, and step thru to just
before the line `(org-export-execute-babel-code)'. At that point have a
look at the temp buffer the exporter is working in. (IIRC, it will have
<2> suffixed to the name of the buffer from which you started the export.)
Then do one more step to run the babel code and look again - be sure it is
*still* the buffer named with the *<2> format that you are inspecting now.
You will see what it is that Babel has done.
In particular, a src block with no results initially, but with
`:exports results' as a header will be gone, but results will now be
seen.
A src block that is has `#+begin-src emacs-lisp :exports code' will
survive, but the header arg will be gone. So, transcoders in the
exporter will not see the header arg.
>
> In fact, I just had an idea... I have o-e-b-e set to always, but just
> turned org-confirm-babel-evaluate to on (I typically have it off). If
> export the above and type "no" to make sure the code block is not
> executed I do *not* get the code in the document. I think this
> confirms that babel's responsibilities include *what* plain text in
> .org the exporter formats into the output format.
>
> My suggestion would be to create a different variable to handle
> formatting vs. execution unless things were designed this way? It
> seems from all the comments that the majority of users expect the
> time-heavy *code* not to be run at each export but still prefer the
> blocks to behave as they intended.
This is what `:eval never-export' was created for.
> Theoretically, with all of my
> results generated (e.g. into .pdf, .png, etc. plots; ascii tables,
> whatever) shouldn't I be able to have o-e-b-e set to whatever and get
> the same document? My document no longer depends on any of the code...
> so I don't need it run, but the exported document will behave like
> :exports both instead of :exports results just from turning babel off.
>
It sounds simple, but babel has a lot woven into it and getting the
behavior you suggest by setting variables like o-e-b-e in emacs without
breaking things is tricky. Consider what happens when you have something
like:
#+BEGIN_SRC emacs-lisp :var x=abc() :noweb yes :exports both
<<format-some-code(y=x)>>
#+END_SRC
With o-e-b-e nil, what should happen? If nothing runs, x does not get set
because abc() does not run, nor does the noweb code substitution take
place because that requires the `format-some-code' src-block to run. If
only some things `ought to' be run, how does the program decide which
ones?
Currently, the user can fine tune what is run and what is not during
export using Babel headers. Let babel run and the headers will sort
out the rest.
Frankly, I do not see why users would want to mess with o-e-b-e except
in unusual cases - like debugging a complicated document, where having
Babel changing things around could just make things harder.
If there is a use case for a capability that is not well supported by
existing headers it would be good to have an example.
[snip]
next prev parent reply other threads:[~2016-05-22 21:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 15:57 exporting documents w/ babel results w/o evaluating babel blocks Ken Mankoff
2016-05-20 16:14 ` John Hendy
2016-05-20 16:45 ` Ken Mankoff
2016-05-20 17:25 ` John Hendy
[not found] ` <878addc2b6b14ce99e907921f0985d24@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2016-05-20 16:59 ` Eric S Fraga
2016-05-20 17:06 ` Ken Mankoff
[not found] ` <b29fde01938940d3b115abd9b257dc57@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2016-05-20 17:11 ` Eric S Fraga
2016-05-20 17:23 ` John Hendy
2016-05-20 17:38 ` Ken Mankoff
2016-05-20 17:32 ` Ken Mankoff
2016-05-20 18:46 ` Nick Dokos
2016-05-20 21:20 ` Charles C. Berry
2016-05-21 19:01 ` Nick Dokos
2016-05-22 19:58 ` John Hendy
2016-05-22 21:52 ` Charles C. Berry [this message]
2016-05-23 18:27 ` Nick Dokos
2016-05-23 18:34 ` John Hendy
2016-05-23 20:08 ` Charles C. Berry
2016-05-24 1:34 ` Grant Rettke
2016-05-24 10:17 ` Andreas Kiermeier
2016-05-24 14:32 ` Ista Zahn
2016-05-24 15:09 ` Anthony Cowley
2016-05-24 15:48 ` Charles C. Berry
2016-05-24 15:53 ` Charles C. Berry
2016-05-20 23:06 ` Ken Mankoff
[not found] <0e207e1cbcc44453b29eea98ca5ebe05@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2016-05-20 16:13 ` Eric S Fraga
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.20.1605221317160.813@charles-berrys-macbook.local \
--to=ccberry@ucsd.edu \
--cc=emacs-orgmode@gnu.org \
--cc=jw.hendy@gmail.com \
--cc=ndokos@gmail.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).