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/)]

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/)]

[John Ciolfi]

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"))
 )

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/)]

[Nicolas Goaziou]

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

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/)]

[John Ciolfi]

[-- 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 --]

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/)]

[Nicolas Goaziou]

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

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/)]

[John Ciolfi]

[-- 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 --]

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/)]

[Nicolas Goaziou]

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

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/)]

[Jeremie Juste]

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