Re: Two low-priority questions re: design of org-babel-do-load-languages

[Ihor Radchenko <yantar92@posteo.net>]

Mandar Mitra <mandar.mitra@gmail.com> writes:

> Here's the code from my version of org.el (9.5.5, inbuilt in Emacs 28.2).
>
> (defun org-babel-do-load-languages (sym value)
> ...
> 1. Question from purely a programming student's perspective: this seems to be doing two things: (i) a set-default on line 3, and (ii) actually loading the language support libraries. If one were re-designing from scratch, without worrying about backward compatibility, would it be cleaner to separate the above into

The function `org-babel-do-load-languages' is originally not a generic
function. It is specifically designed to be used as a :set function for
`org-babel-load-languages' variable:

(defcustom org-babel-load-languages '((emacs-lisp . t))
...
  :set 'org-babel-do-load-languages
...)

If you alter `org-babel-load-languages' via customize interface or via
`setopt', the :set function is automatically called.

Later, AFAIK, it was also used in the manual as Elisp function.
Against its original design.

>
> (defun org-babel-do-load-languages () ; no arguments

No arguments is not useful. If we look into the manual section "16.9
Languages", it suggests

       By default, only Emacs Lisp is enabled for evaluation.  To enable or
    disable other languages, customize the ‘org-babel-load-languages’
    variable either through the Emacs customization interface, or by adding
    code to the init file as shown next.
    
       In this example, evaluation is disabled for Emacs Lisp, and enabled
    for R.
    
         (org-babel-do-load-languages
          'org-babel-load-languages
          '((emacs-lisp . nil)
            (R . t)))

So, at least, we should leave some way to provide the enabled/disabled
language list (VAL). Otherwise, I do not see much use in the new version
you propose.

>   "Load the languages defined in `org-babel-load-languages'."
>   (interactive) ; why not?       

If this function is interactive, it is useless. The languages listed in
`org-babel-load-languages' will be loaded during Org startup or each
time user is altering the variable value using customize API. No need to
do further manual loading.

> (defun org-babel-update-loaded-languages (value) ; value seems enough, don't need sym
>   "Update the value of `org-babel-load-languages' and call org-babel-do-load-languages"
>   (set-default ...))

This defeats the purpose of :set. The whole idea is to load the required
libraries when the user alters the value of `org-babel-load-languages'.

> 2. This question https://emacs.stackexchange.com/questions/20577/org-babel-load-all-languages-on-demand asks: is there any way for org-babel to load support for languages when I actually try to use a code block with that language? [as opposed to customising org-babel-load-languages or similar]
>
> and the accepted answer suggests the following:
>
> (defadvice org-babel-execute-src-block (around load-language nil activate)
>   "Load language if needed" ...
>
> What would be the downside of making load-on-demand the default for all languages? Then people wouldn't have to customise org-babel-load-languages.

No downside, but load-on-demand is impossible for all the babel
backends. Not every ob-* library has "*" equal to the language name.
For example, ob-emacs-lisp has

    (org-babel-make-language-alias "elisp" "emacs-lisp")

allowing

#+begin_src elisp
...
#+end_src

in addition to "#+begin_src emacs-lisp ..."

We cannot know in advance, just looking at the language name, which
library should be loaded.

However, using heuristics as suggested in Emacs StackExchange, could be
a viable addition.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>