[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Charles C. Berry
Subject: Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
Date: Mon, 23 May 2016 13:08:49 -0700
User-agent: Alpine 2.20 (OSX 67 2015-01-07)

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



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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]