The modified suggestion:
 (add-to-list 'org-babel-maxima--output-filter-regexps "(linenum:0,$")
also fixes the problem in the cases that I checked.

Benjamin

On Wed, Dec 18, 2024 at 10:06 AM Leo Butler <Leo.Butler@umanitoba.ca> wrote:
On Tue, Dec 17 2024, Ihor Radchenko <yantar92@posteo.net> wrote:

> Leo Butler <Leo.Butler@umanitoba.ca> writes:
>
>> Putting that into the batch file will result in it appearing in the
>> output of the source-code block. We are trying to stop that.
>
> FYI, I have basically no experience with Maxima. So, I was simply
> shooting in the dark. AFAIU, linenum:0 simply sets variable value. If
> setting a value can be done from inside a script...

To explain, Maxima keeps track of the "line numbers" of each complete
input in the variable linenum. When it executes the batch script that
Org sends it, that command is on line 1, so line numbering in the script
would begin at 2. We set linenum to 0 so that the line numbering in the
script starts at 1.

>
>> I think, if the above regexp works for Benjamin, then we should use
>> it. The regexp only matches an incomplete (hence mal-formed) line of
>> input, and so it can only match the errant output that Benjamin is
>> seeing.
>
> Unless we find a better solution, I have no problem with it. It is just
> that regexp filtering can cause issues, like what we keep seeing again
> and again with prompt filtering in ob-shell.

Agreed. One alternative would be to have Maxima add a command-line
option that re-starts line-numbering in a batch file at line 1. That
would not fix Benjamin's problem, in the short term, though.

Leo