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.but...@umanitoba.ca> wrote: > On Tue, Dec 17 2024, Ihor Radchenko <yanta...@posteo.net> wrote: > > > Leo Butler <leo.but...@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
