maxima-discuss — Maxima discussion list

Re: [Maxima-discuss] A `batch' that does not ignore whitespaces?

[Leo B. <Leo...@um...>]

On Mon, Jan 05 2026, Leo Butler <Leo...@um...> wrote:

> Eduardo,
>
> Here is an example. It assumes display2d = true.
>
> We rename PARSE-TYI (src/nparse.lisp) to PARSE-TYI0 and redefine
> PARSE-TYI to be a function that accumulates the stream of input
> characters in the list $INPUT_CHAR_STREAM.
>
> The function $LITERAL_INPUT is used to write 1d output. As mentioned,
> CONTINUE uses the 1d output printer to print input lines (which is how
> $BATCH prints its input lines).
>
> Finally, since $INPUT_CHAR_STREAM may be non-empty, we use a wrapper
> around batch that sets this to nil.
>
> Take a look at %I6--%I8. I think this is what you wanted.
>
> This is not a complete solution, but it provides an idea on how to
> proceed. We would also want to regurgitate comments and all whitespace,
> but comments and some whitespace are handled outside of PARSE-TYI.

This is closer to a solution than I thought. It does regurgitate
whitespace and comments that are in the middle of an input. For example,
the file with contents:

#+begin_src maxima :tangle /tmp/b.mac
infix(".=.") $
a .=. b .=. c;
a    
.=.  /* a comment */
b
.=.
c;

/* a second comment */
#+end_src

will produce: 

#+begin_example
(%i20) mybatch("/tmp/b.mac");

read and interpret /tmp/b.mac
(%I21) infix(".=.") $
(%I22) a .=. b .=. c;
(%o22)                          (a .=. b) .=. c
(%I23) a    
.=.  /* a comment */
b
.=.
c;
(%o23)                          (a .=. b) .=. c
(%o25)                            /tmp/b.mac
#+end_example

Leo

>
> #+begin_example
> (%i1) load("alt-display.mac")$
> (%i2) to_lisp();
>
> Type (to-maxima) to restart, ($quit) to quit Maxima.
>
> MAXIMA> 
> (defun parse-tyi0 ()
>   (let ((tem  *parse-tyi*))
>     (cond ((null tem)
> 	   (tyi-parse-int *parse-stream* *parse-stream-eof*))
> 	  ((atom tem)
> 	   (setq *parse-tyi* nil)
> 	   tem)
> 	  (t ;;consp
> 	   (setq *parse-tyi* (cdr tem))
> 	   (car tem)))))
> (defvar $input_char_stream '())
> (defun parse-tyi ()
>   (let ((x (parse-tyi0)))
>     (if x (push x $input_char_stream))
>     x))
> (defun $literal_input (x)
>   (let ((c-tag (cadr x)))
>     (setf (get 'input  c-tag) (caddr x)
> 	  (get 'vinput c-tag) (reverse $input_char_stream)
> 	  $input_char_stream  '())
>     (format t "(~a) ~{~a~}~%" (stripdollar c-tag) (get 'vinput c-tag))))
>
>
>
> PARSE-TYI0
> MAXIMA> 
> $INPUT_CHAR_STREAM
> MAXIMA> 
> PARSE-TYI
> MAXIMA> 
> $LITERAL_INPUT
> MAXIMA> (to-maxima)
> Returning to Maxima
> (%o2)                                true
> (%i3) mybatch(f) := (input_char_stream:false, batch(f)) $
>
> (%i4) set_alt_display(1,literal_input) $
>
> (%i5) mybatch("/tmp/b.mac");
> (%I6) infix(".=.") $
> (%I7) a .=. b .=. c;
> (%o7)                           (a .=. b) .=. c
> (%I8) a
> .=.
> b
> .=.
> c;
> (%o8)                           (a .=. b) .=. c
> (%o9)                             /tmp/b.mac
> (%i10)
> #+end_example
>
> The contents of /tmp/b.mac:
>
> infix(".=.") $
> a .=. b .=. c;
> a
> .=.
> b
> .=.
> c;
>
> --------------------------
> Re: your approach. It would be easier to do this all in Maxima, using
> the alt-display package. The link I provided shows how to do it with
> html output; latex is easier.
>
>
> Best regards,
> Leo
>
> On Sun, Jan 04 2026, Eduardo Ochs <edu...@gm...> wrote:
>
>> Hi Leo!
>>
>> Thanks, it looks very interesting, but... do you have a minimal
>> example of how to that? For example, can you show us how to push the
>> lines "foo;\nbar;\n2+3;\n4+5;\n" into the reader stack?
>>
>> I solved my problem by using this
>>
>>   https://anggtwu.net/2024-piano-roll-macros.html#14:32
>>
>> to send my lines to a Maxima REPL in "display2d:'emaxima" mode, and
>> after that I run a Lua program that processes the log in this way
>>
>>   https://anggtwu.net/eev-emaxima.html#internal-view
>>
>> to convert the output to LaTeX, divided into columns... I was planning
>> to finish the documentation before the New Year's Eve, but now I am
>> busy and sort of panicking trying to finish an article, and the docs
>> will have to wait... now with my tools I can generate LaTeXized Maxima
>> logs like the ones in the screenshot very quickly, but I can't explain
>> the details now... =(
>>
>>   Cheers,
>>     Eduardo
>>
>>
>> On Sun, 4 Jan 2026 at 14:43, Leo Butler <Leo...@um...> wrote:
>>
>>>
>>> I take it that you want %i5 to be printed like %i2 (but maybe with
>>> automatic left-padding?)?
>>>
>>> The problem lies in CONTINUE (src/macsys.lisp) where the input line is
>>> printed thus:
>>>
>>>         (cond ((and batch-or-demo-flag (not *suppress-input-echo*))
>>>           (let (($display2d nil))
>>>             (displa `((mlabel) ,c-tag , $__)))))
>>>
>>> Here, $__ is the parsed input expression. What you want/need is for the
>>> reader to create a stack of input characters that are read and attach
>>> that to $__.
>>>
>>>
>>> Once you have that, you can define a custom 1d printer to print the input
>>> string rather than $__, like here:
>>>
>>> https://github.com/leo-butler/yamwi/blob/embed-graphics/yamwi.mac#L172
>>>
>>> Leo
>>>

Re: [Maxima-discuss] A `batch' that does not ignore whitespaces?

[Eduardo O. <edu...@gm...>]

Works! Fantastic! =) =) =)

I don't have time to understand alt-display.lisp, alt-display.mac,
tex-display.lisp today but I will have very soon!

  Cheers,
    Eduardo =)


On Mon, 5 Jan 2026 at 13:34, Leo Butler <Leo...@um...> wrote:

> Eduardo,
>
> Here is an example. It assumes display2d = true.
>
> We rename PARSE-TYI (src/nparse.lisp) to PARSE-TYI0 and redefine
> PARSE-TYI to be a function that accumulates the stream of input
> characters in the list $INPUT_CHAR_STREAM.
>
> The function $LITERAL_INPUT is used to write 1d output. As mentioned,
> CONTINUE uses the 1d output printer to print input lines (which is how
> $BATCH prints its input lines).
>
> Finally, since $INPUT_CHAR_STREAM may be non-empty, we use a wrapper
> around batch that sets this to nil.
>

Re: [Maxima-discuss] A `batch' that does not ignore whitespaces?

[Leo B. <Leo...@um...>]

Eduardo,

Here is an example. It assumes display2d = true.

We rename PARSE-TYI (src/nparse.lisp) to PARSE-TYI0 and redefine
PARSE-TYI to be a function that accumulates the stream of input
characters in the list $INPUT_CHAR_STREAM.

The function $LITERAL_INPUT is used to write 1d output. As mentioned,
CONTINUE uses the 1d output printer to print input lines (which is how
$BATCH prints its input lines).

Finally, since $INPUT_CHAR_STREAM may be non-empty, we use a wrapper
around batch that sets this to nil.

Take a look at %I6--%I8. I think this is what you wanted.

This is not a complete solution, but it provides an idea on how to
proceed. We would also want to regurgitate comments and all whitespace,
but comments and some whitespace are handled outside of PARSE-TYI.

#+begin_example
(%i1) load("alt-display.mac")$
(%i2) to_lisp();

Type (to-maxima) to restart, ($quit) to quit Maxima.

MAXIMA> 
(defun parse-tyi0 ()
  (let ((tem  *parse-tyi*))
    (cond ((null tem)
	   (tyi-parse-int *parse-stream* *parse-stream-eof*))
	  ((atom tem)
	   (setq *parse-tyi* nil)
	   tem)
	  (t ;;consp
	   (setq *parse-tyi* (cdr tem))
	   (car tem)))))
(defvar $input_char_stream '())
(defun parse-tyi ()
  (let ((x (parse-tyi0)))
    (if x (push x $input_char_stream))
    x))
(defun $literal_input (x)
  (let ((c-tag (cadr x)))
    (setf (get 'input  c-tag) (caddr x)
	  (get 'vinput c-tag) (reverse $input_char_stream)
	  $input_char_stream  '())
    (format t "(~a) ~{~a~}~%" (stripdollar c-tag) (get 'vinput c-tag))))



PARSE-TYI0
MAXIMA> 
$INPUT_CHAR_STREAM
MAXIMA> 
PARSE-TYI
MAXIMA> 
$LITERAL_INPUT
MAXIMA> (to-maxima)
Returning to Maxima
(%o2)                                true
(%i3) mybatch(f) := (input_char_stream:false, batch(f)) $

(%i4) set_alt_display(1,literal_input) $

(%i5) mybatch("/tmp/b.mac");
(%I6) infix(".=.") $
(%I7) a .=. b .=. c;
(%o7)                           (a .=. b) .=. c
(%I8) a
.=.
b
.=.
c;
(%o8)                           (a .=. b) .=. c
(%o9)                             /tmp/b.mac
(%i10)
#+end_example

The contents of /tmp/b.mac:

infix(".=.") $
a .=. b .=. c;
a
.=.
b
.=.
c;

--------------------------
Re: your approach. It would be easier to do this all in Maxima, using
the alt-display package. The link I provided shows how to do it with
html output; latex is easier.


Best regards,
Leo

On Sun, Jan 04 2026, Eduardo Ochs <edu...@gm...> wrote:

> Hi Leo!
>
> Thanks, it looks very interesting, but... do you have a minimal
> example of how to that? For example, can you show us how to push the
> lines "foo;\nbar;\n2+3;\n4+5;\n" into the reader stack?
>
> I solved my problem by using this
>
>   https://anggtwu.net/2024-piano-roll-macros.html#14:32
>
> to send my lines to a Maxima REPL in "display2d:'emaxima" mode, and
> after that I run a Lua program that processes the log in this way
>
>   https://anggtwu.net/eev-emaxima.html#internal-view
>
> to convert the output to LaTeX, divided into columns... I was planning
> to finish the documentation before the New Year's Eve, but now I am
> busy and sort of panicking trying to finish an article, and the docs
> will have to wait... now with my tools I can generate LaTeXized Maxima
> logs like the ones in the screenshot very quickly, but I can't explain
> the details now... =(
>
>   Cheers,
>     Eduardo
>
>
> On Sun, 4 Jan 2026 at 14:43, Leo Butler <Leo...@um...> wrote:
>
>>
>> I take it that you want %i5 to be printed like %i2 (but maybe with
>> automatic left-padding?)?
>>
>> The problem lies in CONTINUE (src/macsys.lisp) where the input line is
>> printed thus:
>>
>>         (cond ((and batch-or-demo-flag (not *suppress-input-echo*))
>>           (let (($display2d nil))
>>             (displa `((mlabel) ,c-tag , $__)))))
>>
>> Here, $__ is the parsed input expression. What you want/need is for the
>> reader to create a stack of input characters that are read and attach
>> that to $__.
>>
>>
>> Once you have that, you can define a custom 1d printer to print the input
>> string rather than $__, like here:
>>
>> https://github.com/leo-butler/yamwi/blob/embed-graphics/yamwi.mac#L172
>>
>> Leo
>>

Re: [Maxima-discuss] A `batch' that does not ignore whitespaces?

[Eduardo O. <edu...@gm...>]

Hi Leo!

Thanks, it looks very interesting, but... do you have a minimal
example of how to that? For example, can you show us how to push the
lines "foo;\nbar;\n2+3;\n4+5;\n" into the reader stack?

I solved my problem by using this

  https://anggtwu.net/2024-piano-roll-macros.html#14:32

to send my lines to a Maxima REPL in "display2d:'emaxima" mode, and
after that I run a Lua program that processes the log in this way

  https://anggtwu.net/eev-emaxima.html#internal-view

to convert the output to LaTeX, divided into columns... I was planning
to finish the documentation before the New Year's Eve, but now I am
busy and sort of panicking trying to finish an article, and the docs
will have to wait... now with my tools I can generate LaTeXized Maxima
logs like the ones in the screenshot very quickly, but I can't explain
the details now... =(

  Cheers,
    Eduardo


On Sun, 4 Jan 2026 at 14:43, Leo Butler <Leo...@um...> wrote:

>
> I take it that you want %i5 to be printed like %i2 (but maybe with
> automatic left-padding?)?
>
> The problem lies in CONTINUE (src/macsys.lisp) where the input line is
> printed thus:
>
>         (cond ((and batch-or-demo-flag (not *suppress-input-echo*))
>           (let (($display2d nil))
>             (displa `((mlabel) ,c-tag , $__)))))
>
> Here, $__ is the parsed input expression. What you want/need is for the
> reader to create a stack of input characters that are read and attach
> that to $__.
>
>
> Once you have that, you can define a custom 1d printer to print the input
> string rather than $__, like here:
>
> https://github.com/leo-butler/yamwi/blob/embed-graphics/yamwi.mac#L172
>
> Leo
>

Re: [Maxima-discuss] A `batch' that does not ignore whitespaces?

[Leo B. <Leo...@um...>]

On Mon, Dec 22 2025, Eduardo Ochs <edu...@gm...> wrote:

> Hi list,
>
> the manual entry for `batch', in
>
>   (info "(maxima)batch")
>
> contains this:
>
>   Spaces, tabs, and newlines in the file are ignored.
>
> Here's an example, as always,
>
> --snip--snip--
> • (eepitch-shell)
> • (eepitch-kill)
> • (eepitch-shell)
> cat > /tmp/b <<'%%%'
> nary("=.");
> a =. b
>   =. c
>   =. d;
> %%%
>
> • (eepitch-maxima)
> • (eepitch-kill)
> • (eepitch-maxima)
> nary("=.");
> a =. b
>   =. c
>   =. d;
> batch("/tmp/b")$
> --snip--snip--
>
> and the log of its part in Maxima:
>
> --snip--snip--
> (%i1) nary("=.");
> (%o1)                                 =.
> (%i2) a =. b
>   =. c
>   =. d;
> (%o2)                          a =. b =. c =. d
> (%i3) batch("/tmp/b")$
>
> read and interpret /tmp/b
> (%i4) nary("=.")
> (%o4)                                 =.
> (%i5) a =. b =. c =. d
> (%o5)                          a =. b =. c =. d
> (%i7)
> --snip--snip--
>
> Is there an easy way to make batch, or some similar function, run
> without deleting the whitespace and the ";"s? That would be very
> useful to me - my current way of LaTeXing Maxima logs has several
> parts that need to be run interactively, and this variant of batch
> would simplify the process a lot...
>
> Hints pointing no not-so-easy ways, like "try to modify the parts such
> and such of the functions such and such in mload.lisp", will probably
> be useful too...

I take it that you want %i5 to be printed like %i2 (but maybe with
automatic left-padding?)?

The problem lies in CONTINUE (src/macsys.lisp) where the input line is
printed thus:

	(cond ((and batch-or-demo-flag (not *suppress-input-echo*))
	  (let (($display2d nil))
	    (displa `((mlabel) ,c-tag , $__)))))

Here, $__ is the parsed input expression. What you want/need is for the
reader to create a stack of input characters that are read and attach
that to $__.


Once you have that, you can define a custom 1d printer to print the input
string rather than $__, like here:

https://github.com/leo-butler/yamwi/blob/embed-graphics/yamwi.mac#L172

Leo

Re: [Maxima-discuss] decruftifying info text, was: Does anyone use the Maxima info files directly?

[Robert D. <rob...@gm...>]

On Sat, Jan 3, 2026 at 4:42 PM Raymond Toy <toy...@gm...> wrote:

> While editing the section about the variable expintrep, I replaced some of the @code things with @mxref so that we get links. However, to get the right links, I had to create new anchors so that when referring to a value of expintrep, such as 'gamma_incomplete, the link would point to the description of the value instead of the gamma_incomplete function. This looks good in html and pdf, but not so good in info. You get text like: "set to *note ‘gamma_incomplete’: expintrep-gamma-incomplete.:" where expintrep-gamma-incomplete is the anchor name.

Hmm, I don't seem to be seeing that. I am working with Texinfo 7.0.3
on Linux. I have updated to commit 2a70d7a; the most recent commit in
doc/info/ is ef6634. Special.texi (after processing Special.texi.m4)
says stuff like

For @mref{expintrep} set to @mxref{expintrep-expintegral-e1, expintegral_e1}:

and the corresponding output in maxima.info-1 is

     For ‘expintrep’ set to ‘expintegral_e1’:

Are you working with a different version of Texinfo or a different commit?

Robert

Re: [Maxima-discuss] Does anyone use the Maxima info files directly?

[Raymond T. <toy...@gm...>]

On 1/3/26 12:42 PM, Raymond Toy wrote:

>
> An alternative would be to build info files twice. One for the online 
> help and one for emacs to get clickable links. I didn't look into how 
> this could be done, though.
>
I looked into it. Just created a new file maxima-info.texi that sets a 
variable to control how info xref's are done. Now the online text manual 
doesn't have the "*note: ..." stuff, but maxima-info.info has the 
expected clickable links.

Not sure if this is the best solution, but it was easy to do, and it's 
easy to maintain.

​

Re: [Maxima-discuss] decruftifying info text, was: Does anyone use the Maxima info files directly?

[Raymond T. <toy...@gm...>]

On 1/3/26 1:58 PM, Robert Dodier wrote:

> On Sat, Jan 3, 2026 at 12:45 PM Raymond Toy<toy...@gm...> wrote:
>
>>       The representation uses *note ‘expintegral_si’:
>> To make the text help look better, I'm inclined not to make these links, which is how they were before. This makes the info file less useful, though.
>>
>> An alternative would be to build info files twice. One for the online help and one for emacs to get clickable links. I didn't look into how this could be done, though.
> Another option is to expunge the cruft (replacing *note <...>: with
> just <...>) via textual substitution at the time stuff is displayed. I
> think the time spent doing that is likely negligible, and users are
> probably not reading huge amounts of reference manual text anyway.
>
> Removing the *note and : will change the layout of the text slightly
> -- I would guess it's going to be no big deal. I haven't tried it.

Interesting idea. Probably easy to do too, except for one thing.

While editing the section about the variable |expintrep|, I replaced 
some of the |@code| things with |@mxref| so that we get links. However, 
to get the right links, I had to create new anchors so that when 
referring to a value of |expintrep|, such as |'gamma_incomplete|, the 
link would point to the description of the value instead of the 
|gamma_incomplete| function. This looks good in html and pdf, but not so 
good in info. You get text like: "set to *note ‘gamma_incomplete’: 
expintrep-gamma-incomplete.:" where |expintrep-gamma-incomplete| is the 
anchor name.

I guess this only adds a little bit of complexity.

Hmm. I also just noticed that in my version of emacs, the info text 
looks like "set to see gamma_incomplete.:" Maybe my version doesn't 
quite understand the format with replacement text? Oh, well. That's not 
our problem.

&#8203;

[Maxima-discuss] decruftifying info text, was: Does anyone use the Maxima info files directly?

[Robert D. <rob...@gm...>]

On Sat, Jan 3, 2026 at 12:45 PM Raymond Toy <toy...@gm...> wrote:

>      The representation uses *note ‘expintegral_si’:

> To make the text help look better, I'm inclined not to make these links, which is how they were before. This makes the info file less useful, though.
>
> An alternative would be to build info files twice. One for the online help and one for emacs to get clickable links. I didn't look into how this could be done, though.

Another option is to expunge the cruft (replacing *note <...>: with
just <...>) via textual substitution at the time stuff is displayed. I
think the time spent doing that is likely negligible, and users are
probably not reading huge amounts of reference manual text anyway.

Removing the *note and : will change the layout of the text slightly
-- I would guess it's going to be no big deal. I haven't tried it.

Robert

Re: [Maxima-discuss] Does anyone use the Maxima info files directly?

[Raymond T. <toy...@gm...>]

On 12/28/25 1:58 PM, Andreas Eder wrote:

> Yes, I do.
> I do almost everything exclusively in emacs.

I've modified some of the mref macros and friends. Links work fine 
still, and as side-effect, if the html file has a link, the info file 
also has a link. I think this is great for users who use emacs to read 
the info files.

However, for the text help, we now get things like:

    |The representation uses *note ‘expintegral_si’: |

In emacs, this just looks like |'expintegral_si'| with the text 
underlined to denote a clickable link.

To make the text help look better, I'm inclined not to make these links, 
which is how they were before. This makes the info file less useful, though.

An alternative would be to build info files twice. One for the online 
help and one for emacs to get clickable links. I didn't look into how 
this could be done, though.

>
>
> 'Andreas
>
> 28.12.2025 20:52:01 Raymond Toy <toy...@gm...>:
>
>     Mostly just curious if anyone uses the Maxima info files in an
>     info reader like Emacs? I don't, but I, of course, use the
>     converted version for the text help but I primarily use the html
>     version.
>
>     It's just that people like me forget that texinfo |@xref| and
>     |@pxref| produce extra text, and it produces really awkward text
>     in the info file at times. These aren't so bad in the text help or
>     the html help. Fixing this for the info file is a pain because it
>     sometimes requires rewriting the text, sometimes producing an
>     equally awkward phrase.
>
>     Because I look at primarily the html help, I don't see the awkward
>     phrasing that might happen.
>
>     I also notice that with the |@mref| and |@mxref| macros, we get
>     nice links in the html file, but the info file is missing the
>     links so you can't click on a link to jump around. You get
>     clickable info links with |@xref|, though.
>
>     &#8203;
>
&#8203;

Re: [Maxima-discuss] Announcing Maxima 5.49

[Wolfgang D. <wol...@da...>]

Am 18.12.25 um 10:20 schrieb Viktor T. Toth:
> Maxima version 5.49 has just been released.
> [...]
> I'd like to ask other contributors to update the Windows and Mac 
> installers, the non-English Web pages, and the documentation.

Dear Maxima-users & developers,

sorry for the delay. I did crosscompile, test and release a Windows 
installer now.
It does contain updated versions of SBCL, wxWidgets and wxMaxima (since 
these projects were updated since the Maxima 5.49.0 release). I 
documented that also in the released Readme.md file.

(Currently 64bit; do we need a 32bit version too?) Windows 10 is out of 
support - and Windows 11 does only exist as 64 bit version.)

Best regards, Wolfgang

[Maxima-discuss] category-macros.texi and texinfo 5.1

[Raymond T. <toy...@gm...>]

While trying to figure out why the pdf file doesn't use the alternative 
text given by |@mxref|, I discovered that there are many separate 
definitions for |@mxref| and friends. I think the html docs and the pdf 
doc can all use the same definition for |@mxref| (once it's updated to 
use the 3-arg form of |@ref|). I don't know why we do something 
different for info files.

The logic is also pretty hard to follow because texinfo doesn't have a 
very nice set of conditionals.

In addition, there are a set of macros |@nref|, |@nxref|, and so on. 
These don't appear to be used anywhere, so I propose on removing these. 
I can see that they might be useful, but we aren't using them, so it's 
just extra clutter (times 3 for html/pdf/info).

Finally, while looking into these macros, I tried generating the manual 
using Texinfo 5.1. It can't process format.texi. Can we drop support for 
Texinfo 5.1? It is really old and does a terrible job for html on small 
screens.

​

Re: [Maxima-discuss] proposal for new built-in functions for ordering and ranking

[El O. De M. <obs...@gm...>]

Hi, and Happy New Year.

It is a good exercise; combinatorics has some useful functions implemented.

Here is a naive approach:

 --> load(combinatorics);
 --> ordering(list):=block(
   counter:1,
   original_list:list,
   len:length(list),
   ordered_list:sort(list),
   while list#ordered_list do (
       list:permute(first(perms_lex(len,counter)),original_list),
       counter:counter+1
   ),
   perms_lex(len,counter)
)$
 --> ordering_tj(list):=block(
   counter:1,
   original_list:list,
   len:length(list),
   ordered_list:sort(list),
   while list#ordered_list do (
       list:permute(perm_unrank(len,counter),original_list),
       counter:counter+1
   ),
   perm_unrank(len,counter)
)$

Surely an experienced developer can do it better.

best

El jue, 1 ene 2026 a las 17:06, Robert Dodier (<rob...@gm...>)
escribió:

> I've created a ticket on the new features tracker
> (https://sourceforge.net/p/maxima/feature-requests/199/) for two new
> built-in functions, 'ordering' and 'ranks'. If anyone has any comments
> on that, I would be glad to hear it.
>
> All the best and happy new year.
>
> Robert
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

[Maxima-discuss] proposal for new built-in functions for ordering and ranking

[Robert D. <rob...@gm...>]

I've created a ticket on the new features tracker
(https://sourceforge.net/p/maxima/feature-requests/199/) for two new
built-in functions, 'ordering' and 'ranks'. If anyone has any comments
on that, I would be glad to hear it.

All the best and happy new year.

Robert

Re: [Maxima-discuss] Does anyone use the Maxima info files directly?

[Leo B. <Leo...@um...>]

On Mon, Dec 29 2025, Raymond Toy <toy...@gm...> wrote:

> On 12/28/25 1:58 PM, Andreas Eder wrote:
>
>> Yes, I do.
>> I do almost everything exclusively in emacs.

+1

> Just in case, I wasn't proposing to remove it. I was just curious on
> how much effort to make sure the info manual reads nicely. I generally
> focus on the html docs because that's what I usually use.

I came across this issue with `mref' recently when I was correcting
documentation and had occasion to compare the info and html docs. The
info manual is missing a lot of cross-references compared to the html.
I think this could be fixed by defining `mref' for info to just expand
into `ref', but I am not sure.

Other features that are missing in the info docs is graphics and
pretty-printing math typesetting. Graphics are possible in a window-ed
emacs; I am not sure about pretty-printing math.

Leo

Re: [Maxima-discuss] mref vs xref

[Raymond T. <toy...@gm...>]

On 12/28/25 11:17 PM, Robert Dodier wrote:

> On Sat, Dec 27, 2025 at 3:48 PM Raymond Toy<toy...@gm...> wrote:
>
>> You generally need to have something. Otherwise what used to be @xref{beta} for examples which outputs "See beta for examples" now becomes "beta for examples" if you replace @xref with just @mref. Adding @mxref makes it easy to replace @xref.
> @xref{beta} doesn't output "See beta", it outputs "*Note beta::",
> although I don't think "*See beta::" would be any improvement.

There seems to be a problem with using |@mref| and |@mxref|. I don't 
seem to get clickable links in the info file when viewed with emacs. I 
tried with texinfo 7.2 and 7.2.90. But you change |@mref/@mxref| to 
|@xref|, the links are clickable. The html docs work just fine.

Could someone else who builds docs confirm this?

Also, |@mxref| has a bug in it that the second arg isn't used as the 
label in the pdf output. You get the node name. This is (should be) 
fixed by using the 3-arg form of |@ref| where the 2nd arg is empty. 
Well, this also doesn't work for me. But if I replace |@mxref| with the 
3-arg |@ref| form, it works. These look like makeinfo bugs, but I'm 
trying to find out from the texinfo devs.

Can an info user confirm that links aren't clickable? You'll need to 
check the sources to see if the link used |@mref| vs |@ref|, though. I 
assume that this really does matter for the info users.

&#8203;

Re: [Maxima-discuss] trivial permutations and cycles in the combinatorics package

[Jaime V. <vi...@fe...>]

I have nothing against returning true in those cases.

Jaime

On 12/30/25 05:43, Robert Dodier wrote:
> Maxima has a share package "combinatorics" (thanks to Jaime Villate).
> The package has predicates permp for testing permutations and cyclep
> for testing cycles.
>
> permp([]) and permp([1]) both return false; from what I can tell,
> under conventional definitions, those should both be true. What does
> anyone think about that?
>
> cyclep([], 0), cyclep([], 1), and cyclep([1], 1) all return false; I
> am thinking those should all return true. Thoughts?
>
> Thanks for any insights you may have.
>
> Robert

Re: [Maxima-discuss] trivial permutations and cycles in the combinatorics package

[Andreas E. <and...@gm...>]

On Mo 29 Dez 2025 at 21:43, Robert Dodier wrote:

> Maxima has a share package "combinatorics" (thanks to Jaime Villate).
> The package has predicates permp for testing permutations and cyclep
> for testing cycles.
>
> permp([]) and permp([1]) both return false; from what I can tell,
> under conventional definitions, those should both be true. What does
> anyone think about that?
>
> cyclep([], 0), cyclep([], 1), and cyclep([1], 1) all return false; I
> am thinking those should all return true. Thoughts?

I am not a combinatorialistm but I think you are right. In all these cases the calls should return true.

Andreas

-- 
ceterum censeo redmondinem esse delendam

[Maxima-discuss] trivial permutations and cycles in the combinatorics package

[Robert D. <rob...@gm...>]

Maxima has a share package "combinatorics" (thanks to Jaime Villate).
The package has predicates permp for testing permutations and cyclep
for testing cycles.

permp([]) and permp([1]) both return false; from what I can tell,
under conventional definitions, those should both be true. What does
anyone think about that?

cyclep([], 0), cyclep([], 1), and cyclep([1], 1) all return false; I
am thinking those should all return true. Thoughts?

Thanks for any insights you may have.

Robert

[Maxima-discuss] [better SOLVED] Multiple Gnuplot windows?

[Jérémy B. <jer...@gm...>]

set_plot_option([plot_format, gnuplot]);

works! Thanks.

https://maxima.sourceforge.io/docs/manual/maxima_singlepage.html#Plotting-Formats
is not clear about this...

I'm on PC Arch Linux KDE btw.

Re: [Maxima-discuss] [SOLVED] Multiple Gnuplot windows?

[Robert D. <rob...@gm...>]

On Sun, Dec 28, 2025 at 5:46 AM Jérémy Bézairie
<jer...@gm...> wrote:

> Why only 1 Gnuplot window by default? Isn't it strange? So every time write ,[window,n] ...

I find that if I say

set_plot_option ([plot_format, gnuplot]);

then a new window is opened for every call to plot2d or plot3d. I am
working on Linux -- I don't know if it works differently on Windows or
Mac.

The default value for plot_format, on Linux at least, is
gnuplot_pipes, which means that Maxima maintains a connection with
Gnuplot and sends additional commands for each plot. I don't remember
what capabilities are enabled by this arrangement in contrast to
plot_format being gnuplot, which launches a new instance of Gnuplot
for each plot.

Hope this helps,

Robert

Re: [Maxima-discuss] Does anyone use the Maxima info files directly?

[Raymond T. <toy...@gm...>]

On 12/28/25 1:58 PM, Andreas Eder wrote:

> Yes, I do.
> I do almost everything exclusively in emacs.
Just in case, I wasn't proposing to remove it. I was just curious on how 
much effort to make sure the info manual reads nicely. I generally focus 
on the html docs because that's what I usually use.
>
>
> 'Andreas
>
> 28.12.2025 20:52:01 Raymond Toy <toy...@gm...>:
>
>     Mostly just curious if anyone uses the Maxima info files in an
>     info reader like Emacs? I don't, but I, of course, use the
>     converted version for the text help but I primarily use the html
>     version.
>
>     It's just that people like me forget that texinfo |@xref| and
>     |@pxref| produce extra text, and it produces really awkward text
>     in the info file at times. These aren't so bad in the text help or
>     the html help. Fixing this for the info file is a pain because it
>     sometimes requires rewriting the text, sometimes producing an
>     equally awkward phrase.
>
>     Because I look at primarily the html help, I don't see the awkward
>     phrasing that might happen.
>
>     I also notice that with the |@mref| and |@mxref| macros, we get
>     nice links in the html file, but the info file is missing the
>     links so you can't click on a link to jump around. You get
>     clickable info links with |@xref|, though.
>
>     &#8203;
>
&#8203;

Re: [Maxima-discuss] Does anyone use the Maxima info files directly?

[Raymond T. <toy...@gm...>]

On 12/28/25 2:46 PM, Eduardo Ochs wrote:

> Hi Raymond,
>
> I use the info files, and elisp hyperlinks like this one,
>
>   (info "(maxima)display2d")
>
> all the time, and I know a bit of TeXinfo. Please tell me
> what are the things that I should keep an eye on, and if
> there is anything in which I can help...
Mostly just sentences that look odd. Or links that should work but 
don't. You might have to compare with the html version to know. I think 
those links work.
>
>   Cheers,
>     Eduardo...
>
>
> On Sun, 28 Dec 2025 at 16:47, Raymond Toy <toy...@gm...> wrote:
>
>     Mostly just curious if anyone uses the Maxima info files in an
>     info reader like Emacs? I don't, but I, of course, use the
>     converted version for the text help but I primarily use the html
>     version.
>
>     It's just that people like me forget that texinfo |@xref| and
>     |@pxref| produce extra text, and it produces really awkward text
>     in the info file at times. These aren't so bad in the text help or
>     the html help. Fixing this for the info file is a pain because it
>     sometimes requires rewriting the text, sometimes producing an
>     equally awkward phrase.
>
>     Because I look at primarily the html help, I don't see the awkward
>     phrasing that might happen.
>
>     I also notice that with the |@mref| and |@mxref| macros, we get
>     nice links in the html file, but the info file is missing the
>     links so you can't click on a link to jump around. You get
>     clickable info links with |@xref|, though.
>
>     &#8203;
>     _______________________________________________
>     Maxima-discuss mailing list
>     Max...@li...
>     https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
&#8203;

Re: [Maxima-discuss] mref vs xref

[Raymond T. <toy...@gm...>]

On 12/28/25 11:17 PM, Robert Dodier wrote:

> On Sat, Dec 27, 2025 at 3:48 PM Raymond Toy<toy...@gm...> wrote:
>
>> You generally need to have something. Otherwise what used to be @xref{beta} for examples which outputs "See beta for examples" now becomes "beta for examples" if you replace @xref with just @mref. Adding @mxref makes it easy to replace @xref.
> @xref{beta} doesn't output "See beta", it outputs "*Note beta::",
> although I don't think "*See beta::" would be any improvement.
I was looking at the pdf.
> I don't want @xref or whatever to output the leading bit, because that
> is lost (out of sight, out of mind as my mother used to say) when
I agree with that. I always forget that they output extra stuff that you 
don't see unless you look at the generated file.
&#8203;

Re: [Maxima-discuss] mref vs xref

[Robert D. <rob...@gm...>]

On Sat, Dec 27, 2025 at 3:48 PM Raymond Toy <toy...@gm...> wrote:

> You generally need to have something. Otherwise what used to be @xref{beta} for examples which outputs "See beta for examples" now becomes "beta for examples" if you replace @xref with just @mref. Adding @mxref makes it easy to replace @xref.

@xref{beta} doesn't output "See beta", it outputs "*Note beta::",
although I don't think "*See beta::" would be any improvement.

I don't want @xref or whatever to output the leading bit, because that
is lost (out of sight, out of mind as my mother used to say) when
composing the .texi file. Much better to just write the word that is
appropriate for the context, be it "See" or "Note" or "As the case may
be", or whatever.

Yes, I understand that means the existing instances of @xref need to
get fixed up. There aren't very many of them, they're rather
repetitive, it's no big deal.

Robert