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: Thu, 08 Sep 2022 04:38:37 +1000 [thread overview]
Message-ID: <8635d3nhjf.fsf@gmail.com> (raw)
In-Reply-To: <87illzaj8t.fsf@localhost>
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?
next prev parent reply other threads:[~2022-09-07 18:54 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 [this message]
2022-09-09 11:25 ` Ihor Radchenko
2022-09-09 21:56 ` Tim Cross
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=8635d3nhjf.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).