emacs-orgmode
[Top][All Lists]
Advanced

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

Re: Bug: Option to disable evaluation of code blocks during export [9.3.


From: Nicolas Goaziou
Subject: Re: Bug: Option to disable evaluation of code blocks during export [9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/)]
Date: Sat, 13 Jun 2020 11:46:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello,

John Ciolfi <ciolfi@mathworks.com> writes:

> Perhaps, in the interactive C-c C-e mode there could be:
>
>  [C-e] Eval code blocks:  always | never | use-eval-header-setting
>
> where 'use-eval-header-settings' is the default and uses whatever was
> set by the current org file and emacs session. Always and never would
> override that.

As I said, this would add an indirection level to an already complicated
topic.

Moreover, toggles in the export interface are never duplicates from
in-buffer settings, so far. This would set a precedent, and might be
a sign that this isn't right.

> Consider the scenario where a number of people are working on a common
> overall "book" which is constructed from many org-files. The
> "hardcoded" setting of :eval no-export header in individual blocks
> would mean that I cannot interactively enable or disable the
> evaluation of the blocks.

Why would you add :eval no-export to every block in the first place? In
this situation, there should be a global setting, which could be
overridden locally with appropriate header arguments.

Having a global way, even dynamic, to override every setting in the
buffer doesn't seem very useful. It is imprecise; some blocks could
still be used to set up export process. I assume there's a good reason
if a source code block specifies :eval yes.

> Part of my confusion was that it took a little bit to figure this out
> (I ended up debugging the lisp code to get what I wanted). I think
> this could be improved in the doc, though I do admit, I'm not entirely
> clear on all the ways to control evaluation of code blocks during
> export. If I were, I'd propose something for the org manual.

I think the starting point is in (info "(org) Exporting Code Blocks").
Improvements to the manual are welcome, of course.

Regards,
--
Nicolas Goaziou



reply via email to

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