From: Ihor Radchenko <yantar92@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: org-babel-load-languages usability issue
Date: Mon, 05 Sep 2022 19:59:29 +0800 [thread overview]
Message-ID: <877d2ivxpa.fsf@localhost> (raw)
In-Reply-To: <86fsh61a3u.fsf@gmail.com>
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:
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.
> 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.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
next prev parent reply other threads:[~2022-09-05 12:34 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 [this message]
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
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=877d2ivxpa.fsf@localhost \
--to=yantar92@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=theophilusx@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).