Re: org-babel-load-languages usability issue

[Ihor Radchenko <yantar92@gmail.com>]

Tim Cross <theophilusx@gmail.com> writes:

> I'm not sure when the definition of the variable
> org-babel-load-languages changed, but I think we may need to consider
> either reverting it or making some other adjustment.
>
> Originally, this variable was an alist of languages and a boolean
> indicating whether the language should be loaded e.g.
>
> '((emacs-lisp . t)
>   (clojure . t)
>   (sql . nil))
>
> which would load emacs-lisp and clojure, but not sql. However, the
> default value for the variable now appears to just be
>
> '((emacs-lisp . t))

Are you sure? '((emacs-lisp . t)) is the default value in the commit
that introduced this variable 12 years ago:

6e469f4afba4bf7d6e8983d1e4f3e981252f8f60
Author:     Eric Schulte <schulte.eric@gmail.com>
AuthorDate: Fri Jul 2 11:32:38 2010 -0700
babel: `org-babel-load-languages' activates code blocks by language

> This has two consequences. The first is that the doc string for the
> variable is now incorrect. It states in part 
>
> "This list can be used to load support for any of the languages
> below. "

Well. There are actually languages below if you look into the source
code. Indeed, it is confusing in the help/customize buffer. We can fix
this, say, by adding the language list into the docstring itself. Though
it will not cover third-party ob-*.el modules.

> There are no languages listed below. This also leads to the
> next issue. How does a user know what languages are supported and can be
> enabled? Previously, you had a list of all the supported built-in languages -
> most of which would be disabled (nil) by default. However, this did make
> it easy to know what languages are supported - you could use customize
> to change the flag from nil to t (or copy the default into your init
> file and modify appropriately. Now it doesn't seem to be as clear.

The (incomplete) list is actually available in cutomize interface. Of
course, we can still improve the docstring.

> Note also that the doc string refers to the variable as a list, when it
> is actually an alist (association list). This could be confusing,
> especially for new users. The doc string probably should describe the
> format more precisely i.e the CAR of each con cell making up the
> alist is a language syumbol e.g. emacs-lisp and the CDR is a boolean
> that will be 't if the language is to be loaded or nil otherwise. . 

Agreed.

> Should the default value for this variable be a list of all the
> supported babel languages which are bundled with emacs, all of which set to 'nil' to disable them
> except emacs-lisp (to maintain existing semantics, though I do wonder if
> we should also enable eshell given we enable emacs-lisp by default
> because all necessary dependencies are provided by emacs, as is the case
> with eshell)?

The primary goal of this variable is reducing startup time. Loading all
the 44 built-in babel backends would be slow.

-- 
Ihor Radchenko,
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