Re: exporting documents w/ babel results w/o evaluating babel blocks

["Charles C. Berry" <ccberry@ucsd.edu>]

On Mon, 23 May 2016, Nick Dokos wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> 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