On Thu, Sep 07 2023, Ihor Radchenko 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