[Top][All Lists]

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

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src

From: Max Nikulin
Subject: bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
Date: Tue, 28 Dec 2021 18:45:39 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

On 28/12/2021 04:37, Rudolf Adamkovič wrote:
Max Nikulin writes:

Let's consider the following example:

---- >8 ----

#+begin_src elisp
    (message "Test")
---- 8< -----

emacs -Q -L ~/src/org-mode/lisp/ --eval "(custom-set-variables
'(org-babel-load-languages '((emacs-lisp . nil))))" babel-exec.org

Do you agree that "No org-babel-execute function for elisp!" is a
reasonable reaction to `org-babel-execute-buffer`?

The user did ask Org to load "emacs-lisp" but to never execute it.
Thus, I would expect Org to do just that.  What do you think?

No, it means instruction to unload support of emacs-lisp even it was loaded before.

See info "(org) Languages" https://orgmode.org/manual/Languages.html and `org-babel-do-load-languages' function. The latter may be considered too technical for ordinary user, but examples of its usage are excessively proliferated, e.g. it is mentioned for every supported language on Worg https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-octave.html

The function is called when the value of `org-babel-load-languages' is changed through easy customization interface, so (emacs-lisp . nil) is a command rather than a declaration.

The use case is to temporary enable support of some language and later to disable it again without terminating of emacs session. Just to avoid accidental execution of some snippet.

I can not say that your expectation of the effect of nil is a nonsense, but changing its interpretation may cause silent failures and as a result upset users. Consider that a file that includes source code blocks for different languages is moved to another machine (or configuration changed since previous execution on the same machine). It is better to get explicit error than to copy result in a hurry and to discover that it is incomplete some time later. Per-file and per-block configuration is safer against such pitfalls.

I do not insist that current behavior is the best possible. There are still some reasons behind such choice.

reply via email to

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