emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Tim Cross <theophilusx@gmail.com>
To: Org-mode <emacs-orgmode@gnu.org>
Subject: org-babel-load-languages usability issue
Date: Mon, 05 Sep 2022 17:23:11 +1000	[thread overview]
Message-ID: <86fsh61a3u.fsf@gmail.com> (raw)


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

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

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.

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 alternative is to update the doc string. I guess we could reference
the URL to the worg page which lists supported languages. However, I'm
not sure this is a great solution from a usability perspective,
particularly for new org mode users.

next             reply	other threads:[~2022-09-05  8:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05  7:23 Tim Cross [this message]
2022-09-05 11:59 ` org-babel-load-languages usability issue 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

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=86fsh61a3u.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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

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