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: Mon, 05 Sep 2022 23:11:28 +1000 [thread overview]
Message-ID: <86bkru0xim.fsf@gmail.com> (raw)
In-Reply-To: <877d2ivxpa.fsf@localhost>
Ihor Radchenko <yantar92@gmail.com> writes:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> I'm not sure when the definition of the variable
>> org-babel-load-languages changed, but I think we may need to consider
>> either reverting it or making some other adjustment.
>>
>> Originally, this variable was an alist of languages and a boolean
>> indicating whether the language should be loaded e.g.
>>
>> '((emacs-lisp . t)
>> (clojure . t)
>> (sql . nil))
>>
>> which would load emacs-lisp and clojure, but not sql. However, the
>> default value for the variable now appears to just be
>>
>> '((emacs-lisp . t))
>
> Are you sure? '((emacs-lisp . t)) is the default value in the commit
> that introduced this variable 12 years ago:
>
No, not sure at all. It was a long time ago that I last needed to look
at it (I only noticed this now as I'm re-doing my org config as a lot
has changed since much of it was first coded/configured.
> 6e469f4afba4bf7d6e8983d1e4f3e981252f8f60
> Author: Eric Schulte <schulte.eric@gmail.com>
> AuthorDate: Fri Jul 2 11:32:38 2010 -0700
> babel: `org-babel-load-languages' activates code blocks by language
>
>> This has two consequences. The first is that the doc string for the
>> variable is now incorrect. It states in part
>>
>> "This list can be used to load support for any of the languages
>> below. "
>
> 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).
>
>> There are no languages listed below. This also leads to the
>> next issue. How does a user know what languages are supported and can be
>> enabled? Previously, you had a list of all the supported built-in languages -
>> most of which would be disabled (nil) by default. However, this did make
>> it easy to know what languages are supported - you could use customize
>> to change the flag from nil to t (or copy the default into your init
>> file and modify appropriately. Now it doesn't seem to be as clear.
>
> The (incomplete) list is actually available in cutomize interface. Of
> course, we can still improve the docstring.
>
>> Note also that the doc string refers to the variable as a list, when it
>> is actually an alist (association list). This could be confusing,
>> especially for new users. The doc string probably should describe the
>> format more precisely i.e the CAR of each con cell making up the
>> alist is a language syumbol e.g. emacs-lisp and the CDR is a boolean
>> that will be 't if the language is to be loaded or nil otherwise. .
>
> Agreed.
>
>> Should the default value for this variable be a list of all the
>> supported babel languages which are bundled with emacs, all of which set to 'nil' to disable them
>> except emacs-lisp (to maintain existing semantics, though I do wonder if
>> we should also enable eshell given we enable emacs-lisp by default
>> because all necessary dependencies are provided by emacs, as is the case
>> with eshell)?
>
> 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 guess the issue isn't as bad if you do get the list of available
languages when you use the customize interface (I should have checked
that). I never use customise and I know lots of other Emacs users don't
either. Maybe just fixing up the doc string would be sufficient?
next prev parent reply other threads:[~2022-09-05 13:28 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 [this message]
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
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=86bkru0xim.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).