all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Mandar Mitra <mandar.mitra@gmail.com>
Cc: emacs orgmode-mailinglist <emacs-orgmode@gnu.org>
Subject: Re: Two low-priority questions re: design of org-babel-do-load-languages
Date: Wed, 22 Mar 2023 12:55:31 +0000	[thread overview]
Message-ID: <878rfpndx8.fsf@localhost> (raw)
In-Reply-To: <20230321192515.uvhj4vdpwrztfdkp@gmail.com>

Mandar Mitra <mandar.mitra@gmail.com> writes:

> Here's the code from my version of org.el (9.5.5, inbuilt in Emacs 28.2).
>
> (defun org-babel-do-load-languages (sym value)
> ...
> 1. Question from purely a programming student's perspective: this seems to be doing two things: (i) a set-default on line 3, and (ii) actually loading the language support libraries. If one were re-designing from scratch, without worrying about backward compatibility, would it be cleaner to separate the above into

The function `org-babel-do-load-languages' is originally not a generic
function. It is specifically designed to be used as a :set function for
`org-babel-load-languages' variable:

(defcustom org-babel-load-languages '((emacs-lisp . t))
...
  :set 'org-babel-do-load-languages
...)

If you alter `org-babel-load-languages' via customize interface or via
`setopt', the :set function is automatically called.

Later, AFAIK, it was also used in the manual as Elisp function.
Against its original design.

>
> (defun org-babel-do-load-languages () ; no arguments

No arguments is not useful. If we look into the manual section "16.9
Languages", it suggests

       By default, only Emacs Lisp is enabled for evaluation.  To enable or
    disable other languages, customize the ‘org-babel-load-languages’
    variable either through the Emacs customization interface, or by adding
    code to the init file as shown next.
    
       In this example, evaluation is disabled for Emacs Lisp, and enabled
    for R.
    
         (org-babel-do-load-languages
          'org-babel-load-languages
          '((emacs-lisp . nil)
            (R . t)))

So, at least, we should leave some way to provide the enabled/disabled
language list (VAL). Otherwise, I do not see much use in the new version
you propose.

>   "Load the languages defined in `org-babel-load-languages'."
>   (interactive) ; why not?       

If this function is interactive, it is useless. The languages listed in
`org-babel-load-languages' will be loaded during Org startup or each
time user is altering the variable value using customize API. No need to
do further manual loading.

> (defun org-babel-update-loaded-languages (value) ; value seems enough, don't need sym
>   "Update the value of `org-babel-load-languages' and call org-babel-do-load-languages"
>   (set-default ...))

This defeats the purpose of :set. The whole idea is to load the required
libraries when the user alters the value of `org-babel-load-languages'.

> 2. This question https://emacs.stackexchange.com/questions/20577/org-babel-load-all-languages-on-demand asks: is there any way for org-babel to load support for languages when I actually try to use a code block with that language? [as opposed to customising org-babel-load-languages or similar]
>
> and the accepted answer suggests the following:
>
> (defadvice org-babel-execute-src-block (around load-language nil activate)
>   "Load language if needed" ...
>
> What would be the downside of making load-on-demand the default for all languages? Then people wouldn't have to customise org-babel-load-languages.

No downside, but load-on-demand is impossible for all the babel
backends. Not every ob-* library has "*" equal to the language name.
For example, ob-emacs-lisp has

    (org-babel-make-language-alias "elisp" "emacs-lisp")

allowing

#+begin_src elisp
...
#+end_src

in addition to "#+begin_src emacs-lisp ..."

We cannot know in advance, just looking at the language name, which
library should be loaded.

However, using heuristics as suggested in Emacs StackExchange, could be
a viable addition.

-- 
Ihor Radchenko // yantar92,
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:[~2023-03-22 12:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 19:25 Two low-priority questions re: design of org-babel-do-load-languages Mandar Mitra
2023-03-22 12:55 ` Ihor Radchenko [this message]
2023-03-22 19:21   ` Mandar Mitra

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rfpndx8.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=mandar.mitra@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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.