Re: [O] exporting documents w/ babel results w/o evaluating babel blocks

[Charles C. Berry]

On Mon, 23 May 2016, Nick Dokos wrote:

> "Charles C. Berry" <address@hidden> writes:
>
> > 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'.
> >
> > ...
[snip]

> > 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.
>
> OK - but then users need guidance that says "don't do that!". Can we add a
> big warning to the doc for o-e-b-e?


Seems like a good idea.

> > 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.
>
> There's the use case that John describes: I've evaluated everything,
> checked everything, I'm ready for export, I don't want babel to touch
> the results - and I have a million blocks, so I'd rather have a global
> setting than go in with individual headers.
>
> If you've covered this in a previous reply, please ignore me: I've only
> paid intermittent attention to the thread, so apologies for missing a
> big chunk of what has gone on before in the thread.

Kinda covered it before, but just to elaborate. This line

#+PROPERTY: header-args :eval never-export

will allow interactive execution via the `org-babel-execute-*' functions. 
So you can redo one src block, all src blocks in a subtree, or all src 
blocks in the buffer as you would with `:eval yes'. But on export, it acts 
like `:eval no'.

And of course, the global setting can be overridden by the headers on
individual src blocks, so finer control is possible.

Chuck