From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id GOeMMqC1+WRXXwAA9RJhRA:P1 (envelope-from ) for ; Thu, 07 Sep 2023 13:36:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id GOeMMqC1+WRXXwAA9RJhRA (envelope-from ) for ; Thu, 07 Sep 2023 13:36:00 +0200 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 233FF359F1 for ; Thu, 7 Sep 2023 13:35:59 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Z19+NSMB; 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=1694086560; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Uat5pXHePQqy5JAUbLWMn9S1cnZxyzjW/S3BOKJOt9U=; b=NeeByUGSDTFFl2fJ5bAXimXIlp9LJTyK9VSB+y4XUQmyEBfQ8B1G3vgJW3SNxIRxmCdt+1 VcZoKGcPXPddRaw6VAw4zzM6qrjgPUk8Kz64kFvUkfaqx1FBivRosWasXP15DlysAscppu /ZLgyWxb20mMJPORBhltck26T1Cc+y1OvcLMWJQoS4z19EAS8w+qC2BdvRCDurHzd16mQZ XhZbvKD4+52/BPXp7tmFSGQrMK0Il9VVq/HHUEPbCfIolGMJHyNCl08xxujt84KmvjsvsR ocD4YaLPljKbBANO90zyu7uFNtWqtybl4oO0jtRe0AWi9s3eCZ8RLxJuWa6bUA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694086560; a=rsa-sha256; cv=none; b=Nq1w3KlZIK7RbS2CJE8ji0RejcxEHk+spVJYqmVLpsV7CDMY4hGNYvg/JsHTui6BPsWbmo 9kcPLXmi8DEhSranuwArf0Ok3Z/kwRcxXMLYUmqka5ARSixGn6m55JurANyc3pbZ8AWcBr c4qaJL9VoyTcNYgYo4q9kJTxFYFwEKOnMmHDR+t9yvdQRwnUTBdmyKjVhJf63aBSFqBcKT 13HntNLbUKv7H7ivesLSkOxLhfEjFpSVkHm7rdWbk/QIkToTiO1cYr6TAl02X5rwEQh8Rn XiWaWwxiWIrUj+weW9M/dl+NqFNpNilyWX9G0zYK4US2mCF1TMayLVupUWyTmA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Z19+NSMB; 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 1qeDI0-0006Be-1E; Thu, 07 Sep 2023 07:35:12 -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 1qeDHy-0006BP-5D for emacs-orgmode@gnu.org; Thu, 07 Sep 2023 07:35:10 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeDHr-0001QU-8u for emacs-orgmode@gnu.org; Thu, 07 Sep 2023 07:35:09 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 66AFA240104 for ; Thu, 7 Sep 2023 13:35:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1694086500; bh=32hthWkSq0pe+ccHwUYwisdrowONeSoVetEP5+HAZ7k=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Z19+NSMBOX3RRrzqM9id1xAVtWki3n1pukrf+65H9BIvv2ZCEVpLqbDzVhqx9Hw2m BeMJN/Gz9ZXwWVkv6kU+VtXA/sw2CpP47TL/cx1FcOedQ+6cw+IrBLDqp6/qIHEea2 SJDSgJcGKUhVPhoEydxN+JuRddBKR7/ly3oY1T3YWtUZKAefwHl9QEIWrIcUupvC2E WpjDbsnEYLNwXkvQnzPwGjYTazQs5PB1nvRaI/1tHjiXUNdBJhR8eOwUpkn59OggSR IsheefNt3jpfWqJbxiOVwIEWoDJMkTyNVAuNSBe+MD1wTSriohm2CWmHeNw00L/bxn SJeEbrHxiv1zw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RhHGW5LZqz9rxF; Thu, 7 Sep 2023 13:34:59 +0200 (CEST) From: Ihor Radchenko To: Leo Butler Cc: Bastien , Lockywolf , "emacs-orgmode@gnu.org" Subject: Re: [MAINTENANCE] On how much we can expose internals into defcustom In-Reply-To: <87cyyvdraz.fsf@t14.reltub.ca> References: <874jkemrk2.fsf@laptop.lockywolf.net> <87cyz1ivzw.fsf@t14.reltub.ca> <874jkdhwix.fsf@localhost> <87wmx8h2b0.fsf@t14.reltub.ca> <87il8ovqeg.fsf@localhost> <87cyyvdraz.fsf@t14.reltub.ca> Date: Thu, 07 Sep 2023 11:35:50 +0000 Message-ID: <87ledinrl5.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 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: List-Post: 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-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -6.44 X-Spam-Score: -6.44 X-Migadu-Queue-Id: 233FF359F1 X-TUID: M9JxbHbx1Wvl Leo Butler writes: >> ... >> In order to make such a switch, we will have to force all the users >> change their customization - something we do not want to annoy users >> with. > > I understand your general argument, but I doubt it is relevant to this > particular case. > > In this specific case, that command-line option `--very-quiet' was > introduced in 17 years ago > (https://sourceforge.net/p/maxima/mailman/message/11796355/). The syntax > has not changed since it was introduced. `org-babel-execute:maxima' relies on certain output that maxima produces. Removing --very-quiet will make the assumptions in the code no longer valid. Worse - it might happen that in the absence of --very-quiet `org-babel-execute:maxima' (or its future code) will work _almost_ correctly, with problems going unnoticed to the user. If we want to support use-case when --very-quiet is absent, we need to explicitly change `org-babel-execute:maxima' to account for it, maintaining this support forever. Either way, it will be an extra maintenance burden, which must be justified. The baseline is - we cannot put the burden of wrongly changing customization onto the user. Because the user may or may not notice them problem, especially when it is subtle and requires good knowledge of the Elisp code in ob-maxima. Of course, the above statement is not 100% strict. If you describe cases when customization is necessary for certain valid use cases, we may still put in such dangerous customization with all the appropriate warnings in the docstring. But it should be justified. >> So, leaving essential settings customizeable is not necessarily a good idea. > > I understand your hesitation about full-blown customization using > `defcustom'. However, I would still like to have more dials to turn. > > Perhaps we could add header arguments to get the desired customization? Header arguments are generally better, because they provide more fine-grained control compared to global customization. > E.g. > > - :batch :: Control how the Maxima source is evaluated by Maxima. > 1. Default. If nil or no, then use batchload with the --very-quiet > command-line flag. > 2. If t or yes, then use batch with the --quiet command-line flag; Is there a place where I can see the differences between batch and batchload? > - :plot-engine :: Set the plotting package. > 1. Default. If nil or no, the use `plot'; > 2. If `draw', then use `draw'. Sounds reasonable. > - Similarly, we could do something like ob-R.el does, and construct the > graphics instructions using some additional header arguments and > grovelling the terminal from the filename (see > org-babel-R-construct-graphics-device-call). > > My sense is that this would be more in keeping with how other ob-*.el > packages do things. Yes. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at