[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