From: Ihor Radchenko <yantar92@posteo.net>
To: Leo Butler <Leo.Butler@umanitoba.ca>
Cc: Bastien <bzg@gnu.org>,
Lockywolf <for_org-bugs_2023-09-01@lockywolf.net>,
"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: [MAINTENANCE] On how much we can expose internals into defcustom
Date: Thu, 07 Sep 2023 11:35:50 +0000 [thread overview]
Message-ID: <87ledinrl5.fsf@localhost> (raw)
In-Reply-To: <87cyyvdraz.fsf@t14.reltub.ca>
Leo Butler <Leo.Butler@umanitoba.ca> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-09-07 11:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 4:35 [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)] Lockywolf
2023-09-01 18:33 ` Leo Butler
2023-09-02 7:19 ` Ihor Radchenko
2023-09-02 18:12 ` Leo Butler
2023-09-05 10:57 ` [MAINTENANCE] On how much we can expose internals into defcustom (was: [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]) Ihor Radchenko
2023-09-06 19:39 ` [MAINTENANCE] On how much we can expose internals into defcustom Leo Butler
2023-09-07 11:35 ` Ihor Radchenko [this message]
2023-09-12 21:09 ` [PATCH] ob-maxima.el, etc. (was Re: [MAINTENANCE] On how much we can expose internals into defcustom) Leo Butler
2023-09-15 9:41 ` Ihor Radchenko
2023-09-15 15:13 ` Leo Butler
2023-09-16 9:04 ` Ihor Radchenko
2023-09-19 19:25 ` Leo Butler
2023-09-20 9:17 ` Ihor Radchenko
2023-09-20 15:02 ` Leo Butler
2023-09-21 9:18 ` Ihor Radchenko
2023-09-21 14:03 ` Leo Butler
2023-09-22 9:43 ` Ihor Radchenko
2023-10-02 16:01 ` Leo Butler
2023-10-04 8:38 ` Ihor Radchenko
2023-10-04 13:07 ` Leo Butler
2023-09-02 7:06 ` [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)] Ihor Radchenko
2023-09-02 18:20 ` Leo Butler
2023-09-03 5:25 ` Vladimir Nikishkin
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=87ledinrl5.fsf@localhost \
--to=yantar92@posteo.net \
--cc=Leo.Butler@umanitoba.ca \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=for_org-bugs_2023-09-01@lockywolf.net \
/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 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).