#185 Slight Unicode update for integrals and related

[kcrisman]

Frédéric Chapoton of Sage developers has created a patch for src/displa.lisp that makes integrals and some "bar" displays a little nicer, by using some Unicode options. I don't know whether Maxima is interested in using this kind of thing, but the patch seems pretty innocuous if you do use Unicode for display nowadays, rather than just ASCII.

Patch attached, as well as copied here. Thanks!

diff --git a/src/displa.lisp b/src/displa.lisp
index 6e6582ad9..8d8311d56 100644
--- a/src/displa.lisp
+++ b/src/displa.lisp
@@ -1465,7 +1465,7 @@
 ;; in the 2D case.  This should work for both cases.  (See end of
 ;; program.)

-(defun d-hbar (linear? w &optional (char #\-) &aux nl)
+(defun d-hbar (linear? w &optional (char #\─) &aux nl)
   (declare (ignore linear?))
   (dotimes (i w)
     (push char nl))
@@ -1476,7 +1476,7 @@
 ;; character cell precisely and not get clipped when moving things around in
 ;; the equation editor.

-(defun d-vbar (linear? h d &optional (char #\|))
+(defun d-vbar (linear? h d &optional (char #\│))
   (declare (ignore linear?))
   (setq d (- d))
   (do ((i (- h 2) (1- i))
@@ -1486,7 +1486,7 @@

 (defun d-integralsign (linear? &aux dmstr)
   (declare (ignore linear?))

-  (setq dmstr `((0 2 #\/) (-1 1 #\[) (-1 0 #\I) (-1 -1 #\]) (-1 -2 #\/)))
+  (setq dmstr `((0 2 #\⌠) (-1 1 #\⎮) (-1 0 #\⎮) (-1 -1 #\⎮) (-1 -2 #\⌡)))
   (draw-linear dmstr oldrow oldcol))

 (defun d-prodsign (linear? &aux dmstr)

[kcrisman]

Sorry for possibly creating the ticket in the wrong category, I don't use Sourceforge too much for new tickets. Though I guess it's not really a bug, so maybe it is indeed a feature request?

[Gunter Königsmann]

what does gcl do when using that patch? gcl doesn't support unicode. But sometimes it doesn't break handling unicode - and if the LANG environment variable doesn't end in utf8 what does SBCL do? SBCL outputs utf8 only if that variable tells it to.

[kcrisman]

Good questions. I'll pass them on, but obviously if not all commonly used
lisps can use this it would have to be modified or discarded.

[Robert Dodier]

I think I tried something similar in the not-too-distant past, I would have to look for it. Anyway since there is interest again, maybe we can keep the ball rolling this time.

Any non-Unicode-aware Lisp implementations can just output ASCII characters. Also, it probably makes sense to allow the user to disable Unicode output in case the terminal display doesn't know what to do with Unicode or it gets garbled or something. Maybe establish a global flag display_unicode or something like that, and make it false by default for GCL and true otherwise. Just guessing here.

[Robert Dodier]

I tried the patch with Clisp and SBCL and it works as expected since those are Unicode-enabled. I tried it with GCL 2.6.14 (the most recent released version) and it failed, again, as expected since released versions of GCL are not Unicode-enabled, although I understand that Unicode capability is in the works for GCL.

I expect that this patch will work as expected with all Unicode-enabled Lisp implementations, which is most of them; GCL is the only one that comes to mind which is not.

The hard part of handling this patch is figuring out how to wedge the Unicode characters into the source code in such a way as to avoid causing an error for a non-Unicode Lisp, and, in addition, how to make it possible to enable or disable the new feature, for Lisps that are Unicode-enabled. These aren't difficult problems, I'm just saying that's what we have to figure out. If someone has a proposal on those fronts, that would be great.

If we get through the process for this patch, we can look at pasting in characters for other ASCII-art in the Maxima display, such as summation sign, vertical bar for at, box for box, etc.

[Gunter Königsmann]

AFAIK SBCL and clisp are only unicode-enabled if LANG ends in UTF8...

[Robert Dodier]

AFAIK SBCL and clisp are only unicode-enabled if LANG ends in UTF8...

Looks like that's out of date with respect to SBCL. The NEWS file in the sbcl-2.3.7 (a recentish version) says this (and doesn't otherwise mention LANG):

changes in sbcl-2.0.3 relative to sbcl-2.0.2:

  * incompatible change: the external format now defaults to UTF-8 and is not
    affected by LANG.  SB-EXT:*DEFAULT-EXTERNAL-FORMAT* is now the only way to
    change it.

and, in fact, executing LANG=en_US sbcl and LANG=en_US.UTF-8 sbcl yield the same output for (stream-external-format *terminal-io*), namely (:UTF-8 :REPLACEMENT #\REPLACEMENT_CHARACTER), as expected.

On the other hand, for Clisp, executing LANG=en_US clisp and LANG=en_US.UTF-8 clisp yield different results for (stream-external-format *terminal-io*), namely #<ENCODING CHARSET:ASCII :UNIX> and #<ENCODING CHARSET:UTF-8 :UNIX>, respectively.

I don't know how Maxima would be able to know whether Clisp has enabled UTF-8 or not, short of inspecting LANG. The Clisp documentation about encodings (https://clisp.sourceforge.io/impnotes/encoding.html#enc-dflt) doesn't mention LANG. The Clisp implementation notes (https://clisp.sourceforge.io/impnotes.html) don't mention LANG.

I suppose other implementations may have their own policies about enabling/disabling UTF-8, which we'll have to handle case by case. I think it's probably fairly safe to assume UTF-8 is enabled (except for GCL) and provide a way in Maxima to output only ASCII characters.

[Robert Dodier]

For the record, I made some progress on a proof of concept and posted a message to maxima-discuss about it. See: https://sourceforge.net/p/maxima/mailman/message/52880292/

[Robert Dodier]

Unicode display stuff is now merged into master as of commit 7dac7d4, including various commits preceding that; git log -- src/displa.lisp will find them.