Re: org-babel-load-languages usability issue

[Ihor Radchenko <yantar92@gmail.com>]

Tim Cross <theophilusx@gmail.com> writes:

>> 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.
>
> Maybe only add/list those languages 'bundled' with Emacs or perhaps just
> add a link to the worg page listing all the supported languages. I'm
> reluctant to add the list to the doc string as it will make it even
> longer and there will always be the issue of it not being current as
> languages are added/removed (I find doc string drift out more than code,
> where people tend to update/fix code more readily). 

We have [[info:org#Languages]] linking to
https://orgmode.org/worg/org-contrib/babel/languages/index.html
I guess we can simply add the manual link to the docstring. Would it be
sufficient?

>> The primary goal of this variable is reducing startup time. Loading all
>> the 44 built-in babel backends would be slow.
>
> Would it load them if the default values for all the languages which
> have bundleed modes in Emacs were set to nil rather than t?

I am not sure if it is a good idea.
I am now looking at the usage of org-babel-load-languages in the code,
and I am seeing `org-lint-wrong-header-argument',
`org-babel-demarcate-block' ignoring difference between (lang . nil) and
(lang .t).

-- 
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