GNU bug report logs - #52545
29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

Previous Next

Full log

Message #60 received at 52545 <at> debbugs.gnu.org (full text, mbox):

From: Max Nikulin <manikulin <at> gmail.com>
To: 52545 <at> debbugs.gnu.org
Subject: Re: bug#52545: 29.0.50; Make org-babel-execute-buffer ignore
 irrelevant src blocks
Date: Tue, 28 Dec 2021 18:45:39 +0700

On 28/12/2021 04:37, Rudolf Adamkovič wrote:
> Max Nikulin writes:
> 
>> Let's consider the following example:
>>
>> ---- >8 ----
>> Test
>>
>> #+begin_src elisp
>>     (message "Test")
>> #+end_src
>> ---- 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.