[PATCH] Re: [BUG] ob-maxima outputs linenum:0 in results on MacOS

[Leo Butler <Leo.Butler@umanitoba.ca>]

[-- Attachment #1: Type: text/plain, Size: 149 bytes --]

Ihor,

Please find attached the amended patch. All things considered, I think
this is the best option to fix the issue that has arisen.

Leo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-maxima.el-fix-Mac-related-bug.patch --]
[-- Type: text/x-diff; name="0001-lisp-ob-maxima.el-fix-Mac-related-bug.patch", Size: 1598 bytes --]

From db509cf4b81f78a5c85cf12c7f7b2879f2a47397 Mon Sep 17 00:00:00 2001
From: Leo Butler <leo.butler@umanitoba.ca>
Date: Sun, 15 Dec 2024 21:20:26 -0600
Subject: [PATCH] lisp/ob-maxima.el: fix Mac-related bug

* ob-maxima.el (org-babel-maxima--output-filter-regexps): Filter out
lines that end with the literal string "(linenum:0,".  Benjamin
McMillan reports that, on his Mac, this string is appearing in the
Maxima output.  Maxima is echoing part of the command-line arguments
passed to it (but it should not), which appears to be a Mac-specific
problem.  Benjamin reports that the additional regexp removes the
errant strings and that all tests are passed.

Reported-By: Benjamin McMillan
Link: https://list.orgmode.org/87plm2e50v.fsf@localhost/
---
 lisp/ob-maxima.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
index afd615f8d..35438a880 100644
--- a/lisp/ob-maxima.el
+++ b/lisp/ob-maxima.el
@@ -110,7 +110,8 @@ output.  See `org-babel-maxima-expand'.")
 	       "\n")))
 
 (defvar org-babel-maxima--output-filter-regexps
-  '("batch"                     ;; remove the `batch' or `batchload' line
+  '("(linenum:0,$"               ;; remove fragment from command-line (see `org-babel-execute:maxima')
+    "batch"                     ;; remove the `batch' or `batchload' line
     "^rat: replaced .*$"        ;; remove notices from `rat'
     "^;;; Loading #P"           ;; remove notices from the lisp implementation
     "^read and interpret"       ;; remove notice from `batch'
-- 
2.45.2


[-- Attachment #3: ATT00001.txt --]
[-- Type: text/plain, Size: 1835 bytes --]


On Thu, Dec 19 2024, Benjamin McMillan <mcmillanbb@gmail.com> wrote:

> 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