emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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:

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. . 


> 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

  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:

  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 \


* 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


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).