Re: org-babel-load-languages usability issue

[Tim Cross]

Ihor Radchenko <yantar92@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>>> 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.
>
> Done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7c20552ed636d6c058d6be649e19d3d5edc0f62a
>

Excellent. Thanks.

>>>> 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?
>
> Yes, though I am not 100% sure if the impact is significant enough for
> us to care.
>

Agreed.

>> 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.
>
> Agree. 
>
>> 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?
>
> I do not think that your example is a valid use-case.
> (lang . nil), when set during startup, means that (require 'ob-lang) has
> never been executed (or, at least, we cannot guarantee it).
> When (lang . nil) is changed from (lang . t) at some point,
> (require 'ob-lang) is executed, but org-babel-do-load-languages
> explicitly unloads the babel function that executes the LANG blocks.
>
> In general, we cannot assume that any of the ob-lang functions are
> loaded when there is (lang . nil). No LANG-specific info is available.
>
> Also, (lang . nil) is supposed to deny loading LANG. It should be no
> different compared to not listing LANG at all.

OK, fair enough. The point regarding (lang . nil) being supposed to deny
loding LANG is my main point. I would hope it is exactly the same as not
listening LANG. Originally, my thought was it would be easier for the
user from a usability perspective if they could just look at the value
of this variable and immediately see not only the languages currently
enabled, but also those languages which could be trivially enabled
because they are bundled with Emacs - for example, 'shell', 'eshell' and
possibly others which tend to have the runtime installed in most cases
and where Emacs has a built in mode.

At any rate, the changes made are a good start and I'm happy if things
are left there for now.