Tim Cross <theophil...@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.e...@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