[PATCH] ob-maxima.el, etc. (was Re: [MAINTENANCE] On how much we can expose internals into defcustom)

[Leo Butler]

On Thu, Sep 07 2023, Ihor Radchenko <yantar92@posteo.net> wrote:

> `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.

Attached is a patch that tries to address some of Ihor's concerns. I
have added two header arguments for maxima src blocks:

- :graphics-pkg lets the user choose the graphics package to use;

- :batch lets the user choose which source-code loader Maxima will use.

I have also moved two defaults, that were embedded in the code, to
`defvar' forms.

I have added tests in test-ob-maxima.el and in ob-maxima-test.org to
demonstrate the use of these header arguments.

Leo

0001-On-ltb-ob-max-ob-maxima.el-add-headers-and-custs.patch
Description: 0001-On-ltb-ob-max-ob-maxima.el-add-headers-and-custs.patch