From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: org-babel-load-languages usability issue
Date: Sat, 10 Sep 2022 07:56:00 +1000 [thread overview]
Message-ID: <86zgf8jjee.fsf@gmail.com> (raw)
In-Reply-To: <871qsk3i3k.fsf@localhost>
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.
prev parent reply other threads:[~2022-09-09 22:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 7:23 org-babel-load-languages usability issue Tim Cross
2022-09-05 11:59 ` Ihor Radchenko
2022-09-05 13:11 ` Tim Cross
2022-09-07 4:41 ` Ihor Radchenko
2022-09-07 18:38 ` Tim Cross
2022-09-09 11:25 ` Ihor Radchenko
2022-09-09 21:56 ` Tim Cross [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86zgf8jjee.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).