Print matrices using unicode large delimiters (on demand)

[gagern]

Unicode provides nice symbols which can be combined to form large delimiters. It would be nice if we could print matrices using these, instead of the same ASCII brackets on all the lines. So instead of

[1 2|3]
[4 5|6]
[7 8|9]

I'd like to see one of these:

⎛1 2│3⎞    ⎡1 2│3⎤
⎜4 5│6⎟ or ⎢4 5│6⎥
⎝7 8│9⎠    ⎣7 8│9⎦

Perhaps it's best to do this in small increments: start with a keyword argument to the str method of matrices, then later on make this the default. So the ticket here is only for on-demand support of this feature, not for its automatic use by default. For later reference, see #14733 which switched the banner to Unicode, and thereby made the choice that Sage may look broken on non-Unicode terminals.

Component: user interface

Keywords: unicode matrix

Author: Martin von Gagern

Branch/Commit: 6b6f089

Reviewer: Volker Braun

Issue created by migration from https://trac.sagemath.org/ticket/18270

[gagern]

Branch: u/gagern/MatrixUnicodeDelimiters

[gagern]

New commits:

e174830

Trac #18270: Introduce unicode_symbols keyword argument to Matrix.str

[gagern]

Commit: e174830

[videlec]

comment:3

This banner is already a mess. If I ssh + screen + sage at my laboratory, then I got a ugly

�����������������������������������

And then I am not able to see anything else (but still inputting Sage commands work).

The new matrices look nice though. For the on-demand feature it would be nice to have a global flag allowing (or avoiding) unicode

$ sage --with-no-unicode

Vincent

[videlec]

comment:4

Why not only unicode for the argument name?

[gagern]

comment:5

Replying to @videlec:

Why not only unicode for the argument name?

Because in Python 2 unicode names a type as well, and I feared that at some point we might want to convert element types to unicode, thus have to call that coercion function.

[gagern]

comment:6

Replying to @videlec:

This banner is already a mess. If I ssh + screen + sage at my laboratory, …

Perhaps you should file that as a bug, so it can be addressed? Does using screen -U help? What does locale print on your client's terminal, inside the ssh and inside screen respectively?

For the on-demand feature

I meant “on-demand” as opposed to “automatic”, with the demand being expressed for each matrix that gets printed, i.e. by using the keyword argument from my commit. I believe you're talking about something far more automatic here.

it would be nice to have a global flag allowing (or avoiding) unicode

The canonical way, at least on Linux, would be to inspect LC_CTYPE facet of the current locale, and detect whether that refers to UTF8 or not. If one used this to automatically choose a sane default, then setting the LC_CTYPE environment variable manually would serve the same function as the switch you suggest:

$ LC_CTYPE=en_US      sage  # without unicode
$ LC_CTYPE=en_US.utf8 sage  # with unicode

Of course, using en_US in this example is just the common default. I guess you as well as I might be using a different setting there in practice. Adding a switch might still make sense to add visibility to this feature. But all of this should probably be discussed in a follow-up ticket once we get the change here accepted.

[videlec]

comment:7

Replying to @gagern:

Replying to @videlec:

This banner is already a mess. If I ssh + screen + sage at my laboratory, …

Perhaps you should file that as a bug, so it can be addressed? Does using screen -U help? What does locale print on your client's terminal, inside the ssh and inside screen respectively?

Indeed, screen -U solves the problem. My locale on the client is

LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
...

and on the remote is

LANG=C
LANGUAGE=fr_FR:
LC_CTYPE="C"
...

For the on-demand feature

I meant “on-demand” as opposed to “automatic”, with the demand being expressed for each matrix that gets printed, i.e. by using the keyword argument from my commit. I believe you're talking about something far more automatic here.

it would be nice to have a global flag allowing (or avoiding) unicode

The canonical way, at least on Linux, would be to inspect LC_CTYPE facet of the current locale, and detect whether that refers to UTF8 or not. If one used this to automatically choose a sane default, then setting the LC_CTYPE environment variable manually would serve the same function as the switch you suggest:

$ LC_CTYPE=en_US      sage  # without unicode
$ LC_CTYPE=en_US.utf8 sage  # with unicode

Of course, using en_US in this example is just the common default. I guess you as well as I might be using a different setting there in practice. Adding a switch might still make sense to add visibility to this feature. But all of this should probably be discussed in a follow-up ticket once we get the change here accepted.

I like your suggestion very much.

Vincent

[videlec]

comment:8

review comment:

• I would very much prefer that you avoid replace as well as the final step which deals with the top and bottom line. You should rather define all the characters needed as variables at the begining (as you did for left_bracket, right_bracket, etc). That would help for readability and if at some point we decide that all these characters are arguments of the function.
• why not curly bracket?

Vincent