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

[Max Nikulin <manikulin@gmail.com>]

Since debbugs is not the primary bug tracker, it is better to close this 
issue on debbugs and maybe confirm it for https://updates.orgmode.org/

 From my point of view, making babel aware that some widely used 
languages are data-only (so evaluation does not make sense) improves 
user experience.

On the other hand there is no support of BibTeX in babel, so current 
behavior is correct: attempt to execute a block of a language that is 
not enabled causes an error. (While I was reading first messages in this 
thread, it was not obvious for me that there in no ob-bibtex.el package.)

Anyway emacs requires enough customization, so
     (setq org-babel-default-header-args:bibtex '((:eval . "no")))
globally in inti.el or per-file setting
     #+property: header-args:bibtex :eval no
should not be a problem. User can achieve desired behavior with no 
changes in org code.

On 26/12/2021 20:27, Ihor Radchenko wrote:
> 
> Thanks for reminding about `org-babel-load-languages'.
> Note that `org-babel-execute-src-block' (called by
> org-babel-execute-buffer) does not really use it. It just checks for
> (intern (concat "org-babel-execute:" lang)).
> 
> Maybe we just should not throw an error when lang is not in
> `org-babel-load-languages'? Or maybe we can check for this in
> `org-babel-confirm-evaluate'.

Berry, Charles. Fri, 17 Dec 2021 19:25:52 +0000
https://list.orgmode.org/A4FB4F42-64A8-4D6D-A621-D621E1AA1F04@health.ucsd.edu

> If I have a typo in the name of a language, the error message you
> quote tells me what my mistake was.
Certainly, if some language is mentioned in `org-babel-load-languages' 
than it is not a typo, but as I wrote earlier, I do not think, nil 
should work as ":eval no".

Side note: to notify users about a typo, it is better to check all 
source blocks in advance before starting to execute them in 
`org-babel-execute-buffer'. Export may issue warnings as well even when 
evaluation is disabled. See P.S. below for one more note.

I do not mind using `org-babel-load-languages' more widely. However 
massive clean up of worg is required to change abundant examples that 
replace `org-babel-load-languages' by calling 
`org-babel-do-load-languages'. The latter is intended for `defcustom'. 
It is better to provide incremental functions to load and unload 
languages for usage in init files or source blocks. Direct (require 
'ob-something) becomes less favorable as well.

Some symbol like "noeval" may be added to nit and t as values of 
`org-babel-load-languages' pairs.

Berry, Charles. Fri, 31 Dec 2021 19:11:45 +0000.
https://list.orgmode.org/F641D224-52FC-45D8-95F0-9E99F824E1F7@health.ucsd.edu

> #+name: yaml_header_1
> #+begin_export yaml

Rudy wrote that it prevents tangling. I can add that it prevents export 
to e.g. HTML for documentation how to configure something that has two 
representations: executable script and steps that can be followed by 
manually typing commands and editing configuration files.

So I consider data-only languages as a convenient feature.

 From security reasons I would like to have possibility to disable 
evaluation in a such way that it is impossible to override through 
per-file variables or properties.

Are we going to change anything related to `org-babel-load-language' and 
`org-babel-execute-buffer' or maybe just add a set 
`org-babel-default-header-args:something variables'?


P.S.

Berry, Charles. Sat, 18 Dec 2021 20:13:15 +0000.
https://list.orgmode.org/C61FBF93-064B-4FB2-9378-39D3078F108E@health.ucsd.edu

> Also, when exporting it looks `org-babel-exp-results' does not
> attempt  to run src blocks for which
> 
> (fboundp (intern (concat "org-babel-execute:" lang)))
> 
> is nil.
> 
> So doing an export should `just work'.

I would say that it is hardly consistent with mistake detection as a 
feature.