From: Nicolas Goaziou <email@example.com> To: John Ciolfi <firstname.lastname@example.org> Cc: "email@example.com" <firstname.lastname@example.org> 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 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <MN2PR05MB6766969CA28262EFD747DAA0D1810@MN2PR05MB6766.namprd05.prod.outlook.com> (John Ciolfi's message of "Fri, 12 Jun 2020 14:32:26 +0000") Hello, John Ciolfi <firstname.lastname@example.org> 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
next prev parent reply other threads:[~2020-06-13 9:46 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-11 19:55 John Ciolfi 2020-06-11 21:28 ` Nicolas Goaziou 2020-06-11 21:57 ` John Ciolfi 2020-06-12 8:51 ` Nicolas Goaziou 2020-06-12 14:32 ` John Ciolfi 2020-06-13 9:46 ` Nicolas Goaziou [this message] 2020-06-13 12:22 ` Jeremie Juste
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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/)]' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).