Re: [MAINTENANCE] On how much we can expose internals into defcustom

[Ihor Radchenko]

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>