Incorrect alignment of line containing output label when set_display(ascii) is in effect

[robert-dodier]

I'm working with wxMaxima built from Git (commit 96d54eb) on Ubuntu 16.04 + wxwidgets 3.2.5.

I see that when set_display('ascii) has been called, the line containing the output label is aligned incorrectly. It appears that the label is displayed several spaces from the left margin, and the remainder of the line is likewise pushed to the right.

The font is Monospace 12 for both "ASCII maths" (green) and "Standard text" (blue). (See issue #2005 about the unexpected behavior of the color preferences.)

I've attached a screen shot.

[robert-dodier]

If displayed via print, the output is displayed correctly (no output label line).

[daute]

In issue #1969 the same problem was reported - there it seems to be depend on the (monospaced) font???

[robert-dodier]

Yes, I saw #1969, but this is somewhat different. This is specifically about the placement of the output label line -- in the absence of the output label line, the placement of the characters is as expected, at least with Monospace font. (With Latin Modern Mono, I see the same, more mixed-up display as shown in the first example in #1969.)

I'm not sure where to look in the wxMaxima code to see how the label line is being placed; do you have a suggestion?

[daute]

When set_display('ascii) is active, wxMaxima just receives the - not XML encoded - output (with the output prompt in the middle), e.g. (output from the XML-sidebar):

SENT TO MAXIMA:

matrix(
 [0,0,0], 
 [0,0,0], 
 [0,0,0]
);
―
:lisp-quiet (wx-print-gui-variables)


MAXIMA RESPONSE:

                                  [ 0  0  0 ]
                                  [         ]
(%o6)                             [ 0  0  0 ]
                                  [         ]
                                  [ 0  0  0 ]
<PROMPT>(%i7) </PROMPT>

That is not really easy to interpret by wxMaxima (all the XML, which is producing a machine readable output is missing) - and it is not 'distinguishable' from

print("
                                  [ 0  0  0 ]
                                  [         ]
(%o6)                             [ 0  0  0 ]
                                  [         ]
                                  [ 0  0  0 ]");

so just search for "(%onnn)" at the beginning of a line and assume, that that is the output label might be wrong.

Would it make sense to show no output prompt in that case? (e.g. when set_display('ascii) is set? If yes, how can that be done?

Best regards, Wolfgang

[robert-dodier]

I don't think it makes sense to remove or suppress the output label when set_display(ascii) is in effect.

I see two ways of handling the output label; these two are both OK by me. (1) Display all output returned from Maxima the same; make both the font and the color the same for the output label and the output.

(2) Make the font the same for the output label, and color it differently. I think it's OK if the colorizer can' t tell the difference between an output label constructed by Maxima and one which happens to be introduced by print as in the example you showed.

[gunterkoenigsmann]

What I am still wondering is if we can find a good solution for the following problem:

• Maxima doesn't tell us if this is a 2D equation, or text created by printf()
• we don't even know if the command we are currently processing will output 2D XML equations that we want to indent, and
• if the output of printf() is by a command that outputs 2D XML we definitely want to indent it.

=> The answer to the question if wxMaxima should indent the text depends on the formatter maxima is instructed to use.

Emacs would provide us with a hook that allows wxMaxima to subscribe to "Maxima was switched to 2D XML" or "Maxima was switched to ASCII Art/1D/ASCII Art+Unicode". In theory we could poll that information from maxima after every single command we send to it. But that would double the number of commands maxima needs to process and would make everything slow: Currently we read out all maxima variables whose value interests us. But we do so only if there really isn't anything else to do.

Modifying maxima from wxMaxima to contain hooks or similar stuff isn't nice, as it means that we do something that will break maxima if the way maxima works ever changes.

[robert-dodier]

Gunter, that's a rather bigger problem, and I don't think we need to solve it in order to make progress on this particular bug report. The minimal change would be item 1 in my comment above; slightly more complex but still not very big would be item 2.