From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id C28XBor6GmRyLAAASxT56A (envelope-from ) for ; Wed, 22 Mar 2023 13:54:34 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id wLQSBYr6GmR0ggEAauVa8A (envelope-from ) for ; Wed, 22 Mar 2023 13:54:34 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B8407164D5 for ; Wed, 22 Mar 2023 13:54:33 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=OqbkcFEG; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1679489673; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=775BbG3IMr6OO+3kH4Gi5k0PVQLxDSbjd9qliGURbho=; b=NN+ONGlF6MpaOpkBwkkM9JAsM1DUedaoFZDKSNAFlyu/4vLnsxn2+UoGzXooqLezal6qK9 gJReby+rZYvXZtd744/BGM24L8XqLPKwtOHVx98Miz7fAWAEmRc7SYWyHLNtKGd38F2amS QqvfZZeBd0soWJtDPF2VRf1j2uPUkk7NrWc3aTlWYfPxb9/npkk3i31trVN8EUzmA/18VT veT4Q3GF8MnfUVIF0sJh8NQabpEiTj/oaDPh3qd6ByUYaD7WglPS+LbOekLeqUoA6e79FV caQWJWSW6pCD+LPw7Fjdt5AJ39kiEZLITL3NJkKxTuPtL48SjH2NFdWD6C+BRQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679489673; a=rsa-sha256; cv=none; b=rAN+gpivjVPS0430QTz3MRmy2Qm0p9x5EvHo4Zopvrl9v+tfdbLVz2ekyfFImfekZ6NbK4 xovY6flvmDb6EuAwXEwGjMKvMx6b5ftn7jaD1+jQv9sR1qcCnaahmUoKH18DkEW2F1vwBg kvi67VVD6/OAAKtD1w+VIJ6ET0xIQrCPwajL22+84qKjo97cRkTvsKZJU63j/IkdbvWwwB JL2mdFdyfriMs23ZWy/B1zfHz7NUv5mK5vASWqEGFzO2b0wJ1TqaMl0XNIDFoTJk+tY5wM 1aPsmoB1y2vYF6nnqTFUoqVTKRanKhBIPfs+zxaW8XiWzNx6QVP3TU4VSDkmAA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=OqbkcFEG; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pexyJ-0005dn-VX; Wed, 22 Mar 2023 08:53:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pexyI-0005de-Jj for emacs-orgmode@gnu.org; Wed, 22 Mar 2023 08:53:42 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pexyG-0005QU-3p for emacs-orgmode@gnu.org; Wed, 22 Mar 2023 08:53:42 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D123D240545 for ; Wed, 22 Mar 2023 13:53:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1679489617; bh=uh0/30RWWjpnGqxMODNVt7y0zp6TKF8r4IMzBcVJ/Js=; h=From:To:Cc:Subject:Date:From; b=OqbkcFEGbvdxaLFJPrp0u1odHdMEmAasNHXAgJET+Jzi23wDAyrtbkP18xF3ufnBV 3Kphjc6Q5CNBSCMkINA2bP/pT2uKaVvm5Uo3gweRJGhS/pzVAaq7Rfmij0P2860EJx oGVVUBfyB5Suxc9M2duPOMOSCWv80zPSpOdYpIYaxLrHpsMgk75Vik1mbbCl9Bv5Qi i0rEOq6rbsHhyJmP5RRIirwqc+rLhHNQkuHZqKagcOruv3/v1jA5ydeC+tz8YiWevX n5ZVZFztEvPEhRAeRdqaDAsLShR4WjXDg7GDDErkBqF5E5sNlQDuhxJ4n5+KjMjXtQ LvgKbC9gCDjAw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PhT1B3rzdz9rxW; Wed, 22 Mar 2023 13:53:34 +0100 (CET) From: Ihor Radchenko To: Mandar Mitra Cc: emacs orgmode-mailinglist Subject: Re: Two low-priority questions re: design of org-babel-do-load-languages In-Reply-To: <20230321192515.uvhj4vdpwrztfdkp@gmail.com> References: <20230321192515.uvhj4vdpwrztfdkp@gmail.com> Date: Wed, 22 Mar 2023 12:55:31 +0000 Message-ID: <878rfpndx8.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: X-Migadu-Scanner: scn0.migadu.com List-Post: X-Migadu-Queue-Id: B8407164D5 X-Spam-Score: -6.57 X-Migadu-Spam-Score: -6.57 List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-TUID: bUDmcQzlLsR+ Mandar Mitra 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 t= o be doing two things: (i) a set-default on line 3, and (ii) actually loadi= ng the language support libraries. If one were re-designing from scratch, w= ithout worrying about backward compatibility, would it be cleaner to separa= te 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 =E2=80=98org-babel-load-language= s=E2=80=99 variable either through the Emacs customization interface, or by adding code to the init file as shown next. =20=20=20=20 In this example, evaluation is disabled for Emacs Lisp, and enabled for R. =20=20=20=20 (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?=20=20=20=20=20=20=20 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, do= n't need sym > "Update the value of `org-babel-load-languages' and call org-babel-do-l= oad-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-babe= l-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 la= nguage? [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 l= anguages? 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. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at