Could you add an option to disable evaluation of code blocks when exporting? If I have an org-file with many code blocks setup for evaulation (babel), when I export, I get prompted for every code block. Also the prompt does not clearly show which code block it's asking to evaluate. One solution would be to have org-export-dispatch have an option at top which says whether or not to evaluate code blocks during export. It should be configurable to be on or off. I would suggest off as I see most of us running the evaluation as we write the code and not during export. I'm able to work around this issue by adding advice, e.g. (defun sb-org-export-dispatch-no-babel (orig-fun &rest args) (let* ((org-babel-default-header-args (cons '(:eval . "never-export") org-babel-default-header-args)) (result (apply orig-fun args))) result)) (advice-add 'org-export-dispatch :around #'sb-org-export-dispatch-no-babel) Thanks John Emacs : GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5) of 2019-09-22, modified by Debian Package: Org mode version 9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/) current state: ============== (setq org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-latex-listings 'minted org-link-shell-confirm-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-html-format-inlinetask-function 'org-html-format-inlinetask-default-function org-latex-default-packages-alist '(("colorlinks=true,linkcolor={red!50!black},citecolor={blue!50!black},urlcolor={blue!80!black}" "hyperref" nil) ("AUTO" "inputenc" t ("pdflatex")) ("T1" "fontenc" t ("pdflatex")) ("" "graphicx" t) ("" "grffile" t) ("" "longtable" nil) ("" "wrapfig" nil) ("" "rotating" nil) ("normalem" "ulem" t) ("" "amsmath" t) ("" "textcomp" t) ("" "amssymb" t) ("" "capt-of" nil) ("" "hyperref" nil)) org-odt-format-headline-function 'org-odt-format-headline-default-function org-latex-pdf-process '("pdflatex -file-line-error -shell-escape -interaction nonstopmode -output-directory %o %f" "pdflatex -file-line-error -shell-escape -interaction nonstopmode -output-directory %o %f") org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default org-mode-hook '(#[0 "\301\211\207" [imenu-create-index-function org-imenu-get-tree] 2] #[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook org-show-all append local] 5] #[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"] org-archive-hook '(org-attach-archive-delete-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-agenda-before-write-hook '(org-agenda-add-entry-text) org-metaup-hook '(org-babel-load-in-session-maybe) org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn ENTRY)"] org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"] org-babel-pre-tangle-hook '(save-buffer) org-tab-first-hook '(org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-link-file-path-type 'relative org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS WIDTH)"] org-occur-hook '(org-first-headline-recenter) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-speed-command-hook '(org-speed-command-activate org-babel-speed-command-activate) org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function org-babel-tangle-lang-exts '(("perl" . "pl") ("D" . "d") ("C++" . "cpp") ("emacs-lisp" . "el") ("elisp" . "el")) org-latex-image-default-width "" org-confirm-shell-link-function 'yes-or-no-p org-link-parameters '(("attachment" :follow org-attach-open-link :export org-attach-export-link :complete org-attach-complete-link) ("id" :follow org-id-open) ("eww" :follow eww :store org-eww-store-link) ("rmail" :follow org-rmail-open :store org-rmail-store-link) ("mhe" :follow org-mhe-open :store org-mhe-store-link) ("irc" :follow org-irc-visit :store org-irc-store-link :export org-irc-export) ("info" :follow org-info-open :export org-info-export :store org-info-store-link) ("gnus" :follow org-gnus-open :store org-gnus-store-link) ("docview" :follow org-docview-open :export org-docview-export :store org-docview-store-link) ("bibtex" :follow org-bibtex-open :store org-bibtex-store-link) ("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete org-bbdb-complete-link :store org-bbdb-store-link) ("w3m" :store org-w3m-store-link) ("file+sys") ("file+emacs") ("shell" :follow org-link--open-shell) ("news" :follow #[257 "\301\300\302Q!\207" ["news" browse-url ":"] 5 "\n\n(fn URL)"]) ("mailto" :follow #[257 "\301\300\302Q!\207" ["mailto" browse-url ":"] 5 "\n\n(fn URL)"]) ("https" :follow #[257 "\301\300\302Q!\207" ["https" browse-url ":"] 5 "\n\n(fn URL)"]) ("http" :follow #[257 "\301\300\302Q!\207" ["http" browse-url ":"] 5 "\n\n(fn URL)"]) ("ftp" :follow #[257 "\301\300\302Q!\207" ["ftp" browse-url ":"] 5 "\n\n(fn URL)"]) ("help" :follow org-link--open-help) ("file" :complete org-link-complete-file) ("elisp" :follow org-link--open-elisp) ("doi" :follow org-link--open-doi)) org-latex-format-headline-function 'org-latex-format-headline-default-function org-latex-logfiles-extensions '("aux" "bcf" "blg" "fdb_latexmk" "fls" "figlist" "idx" "nav" "out" "ptc" "run.xml" "snm" "toc" "vrb" "xdv") org-link-elisp-confirm-function 'yes-or-no-p org-latex-format-inlinetask-function 'org-latex-format-inlinetask-default-function org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"] org-latex-packages-alist '(("cache=false" "minted")) org-html-format-headline-function 'org-html-format-headline-default-function org-list-indent-offset 2 org-latex-minted-options '(("xleftmargin" "1em") ("breaklines" "true") ("fontsize" "\\small")) )
Hello,
John Ciolfi <ciolfi@mathworks.com> writes:
> Could you add an option to disable evaluation of code blocks when exporting? If I
> have an org-file with many code blocks setup for evaulation (babel), when I export, I get
> prompted for every code block. Also the prompt does not clearly show which code block it's
> asking to evaluate.
What is wrong with :eval no-export header? You can set it globally,
file-wise, tree wise, or per block.
Regards,
--
Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --] It would be very nice if I could enable/disable the evaluation of code blocks during the export process in the interactive C-c C-e environment. I do now see that I can use the :eval no-export header more effectively, so this is less of an issue, but still think it would be a nice enhancement to have control from within the interactive org-export-dispatch function. Thanks John ________________________________ From: Nicolas Goaziou <mail@nicolasgoaziou.fr> Sent: Thursday, June 11, 2020 5:28 PM To: John Ciolfi <ciolfi@mathworks.com> Cc: emacs-orgmode@gnu.org <emacs-orgmode@gnu.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/)] Hello, John Ciolfi <ciolfi@mathworks.com> writes: > Could you add an option to disable evaluation of code blocks when exporting? If I > have an org-file with many code blocks setup for evaulation (babel), when I export, I get > prompted for every code block. Also the prompt does not clearly show which code block it's > asking to evaluate. What is wrong with :eval no-export header? You can set it globally, file-wise, tree wise, or per block. Regards, -- Nicolas Goaziou [-- Attachment #2: Type: text/html, Size: 2622 bytes --]
Hello,
John Ciolfi <ciolfi@mathworks.com> writes:
> It would be very nice if I could enable/disable the evaluation of code
> blocks during the export process in the interactive C-c C-e
> environment.
I'm not sold to this idea. There are already many ways to control
evaluation of Babel code, i.e., :eval header arguments in its multiple
forms, `org-export-use-babel'.
Adding one more could also add confusion.
Regards,
--
Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 1755 bytes --] Hi 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. 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. 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. Thanks John ________________________________ From: Nicolas Goaziou <mail@nicolasgoaziou.fr> Sent: Friday, June 12, 2020 4:51 AM To: John Ciolfi <ciolfi@mathworks.com> Cc: emacs-orgmode@gnu.org <emacs-orgmode@gnu.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/)] Hello, John Ciolfi <ciolfi@mathworks.com> writes: > It would be very nice if I could enable/disable the evaluation of code > blocks during the export process in the interactive C-c C-e > environment. I'm not sold to this idea. There are already many ways to control evaluation of Babel code, i.e., :eval header arguments in its multiple forms, `org-export-use-babel'. Adding one more could also add confusion. Regards, -- Nicolas Goaziou [-- Attachment #2: Type: text/html, Size: 4148 bytes --]
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
Hello,
I understand the frustration of not being able to bend emacs to ones
immediately. But many times my initial workflow turned out not to be the
best one. I just wanted to share my workflow hoping that it might be a solution to
the original post problem.
>> 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.
At some point, I experienced the same problem and as the document get
larger and larger it tends to complicate the management of code block
evaluation. I have found two solutions to this problem using existing
org-mode features.
* First
use global property header :eval yes, but evaluate only the sub-tree of
interest when the need comes. For a book it might be a part, a chapter
(even a paragraph by artificially creating a sub-tree at the desired
point). In that way you have only one trigger to push to disable
evaluation for the entire document.
To makes things quicker one can define a way to change :eval
from yes to no very quickly. (I use point registers for this purpose
(info "(emacs) Registers"), but you could imagine a function with
key-bindings)
* Second
The second solution could be to use checkpoints with cache for
instance. Let say that, one wants to work on Part 1 only and wants to
evaluate code just for this part then. The following work flow might be suitable.
* Part 1
:PROPERTIES:
:header-args: :eval yes :cache yes
:END:
#+BEGIN_SRC matlab
A = [16 3 2 13; 5 10 11 8; 9 6 7 12; 4 15 14 1]
#+END_SRC
** strip the header row
#+BEGIN_SRC matlab
A = [1 ; 2], B = A.', C = transpose(A)
#+END_SRC
* Part 2
:PROPERTIES:
:header-args: :eval no :cache yes
:END:
#+BEGIN_SRC matlab
ones(3,3)
#+END_SRC
HTH,
Jeremie