[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: John Hendy
Subject: Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
Date: Mon, 23 May 2016 13:34:37 -0500

On Mon, May 23, 2016 at 1:27 PM, Nick Dokos <address@hidden> wrote:
> "Charles C. Berry" <address@hidden> writes:


>> 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.

I actually have never used o-e-b-e prior to this thread. I just dove
in as I was curious about it. My solution is using :eval yes/no as
desired. I often fiddle with blocks one by one, and when I'm done and
want to export the whole doc, my "file-wide" solution is simply:

M-x replace-string RET :eval yes RET :eval no

Works great for me. It can be a little tedious to find a mistake and
quick change no -> yes just to C-c C-c on it and then turn yes -> no,
but it works well enough. I can't see toggling a system-wide variable
related to babel execution as being any less cumbersome, actually.

After all the hoopla about o-e-b-e being a bad idea, and learning that
it doesn't just handle eval but formatting, too, I wonder what the
purpose of the variable *is* for?


> In any case, although I'm not happy about the state of things, I
> understand better why they are as they are.
> Thanks!
> --
> Nick

reply via email to

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