Re: org-babel-load-languages usability issue

[Tim Cross <theophilusx@gmail.com>]

Ihor Radchenko <yantar92@gmail.com> writes:

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

Yes, I think so. That was what I was thinking would be reasonable and
would avoid maintenance issues for the doc string when languages are
added/removed.


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

OK, so if I understand you correctly, not all of org code honours the
enabled/disabled setting so adding all bundled languages, but setting
them to nil, would result in unexpected or additional processing for
those languages despite them being disabled?

If that is the case, you right and adding them would be
problematic. However, I would also argue this is probably a
bug. Essentially, it means that the value associated with the language
symbol key is sometimes interpreted and sometimes ignored. I think this
is an inconsistency which can potentially cause confusion and could
contribute to subtle bugs.

One thing I do wonder though wrt the two examples you cited. Could this
be deliberate/intentional for these functions?

I wondering about the scenario where you want to include blocks for a
certain language, but you do not need to evaluate them, so no need for
babel support. Might this be a case where you would set the language to
nil, but be fine with lint and other checks verifying the block
structure? Provided this isn't also resulting in loading of language
specific babel code, it may not be an issue?