On Mon, 23 May 2016, Nick Dokos wrote:
"Charles C. Berry" <ccbe...@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
