Re: Display of undisplayable characters: \U01F3A8 instead of diamond

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 28 Aug 2022 00:04:51 -0400
> 
>   > Is this specifically about that U+1F3A8 character?  Or is this more
>   > general?
> 
> This applies to all characters that display that way.  I don't know
> what U+1F3A8 stands for; to me, it is simply "some undisplayable character."

In that case, you can significantly improve the situation by typing

   M-x latin1-display-ucs-per-lynx RET

or by using "M-x customize-variable" to customize the variable
latin1-display-ucs-per-lynx to a non-nil value.  Then many non-ASCII
characters will be displayed as ASCII emulations.  Some characters
will inevitably be still not displayable; for those you can define
their ASCII representation like this:

  (set-char-table-extra-slot glyphless-char-display 0 "*")

Then the characters that cannot be displayed will be represented by
the string that is the last argument to set-char-table-extra-slot,
with a special face designed to make those stand out.  The string must
be ASCII, though, because nothing else is safe to serve as fallback.

(With the latest master branch, if the string is a single character,
it will not be enclosed in [..], so you can effectively use that
single character as a replacement character for those your terminal
cannot display.  It still has to be an ASCII character.)

>   > This is a standard Emacs way of displaying unsupported characters on
>   > TTY frames.  I fail to see how this is worse than displaying the same
>   > diamond glyph for any unsupported character, because with the
>   > character codes you at least know when the characters are different,
>   > even without "C-u C-x =".
> 
> This change makes it harder to see and recognize the displayable
> characters in the line.

I don't think I understand how this is possible.  The \Unnnn thing has
a distinct face.  Maybe you need to customize that face to make it
stand out on your terminal?

> When a line contains many nondisplayable characters, this change makes it
> much longer, so the line gets continued.

Only if the line is already long, which is not necessarily true.

Let's not exaggerate problems too much, okay?

> In practice, I can't recognize when the same \U sequence appears more
> than once on the screen.  I can't see what the hex digits are just
> with a glance; only if I concentrate and read one.  If I do that, I
> can't recognize other instances of the same sequence without
> concentrating on each of them to read it.

This still sounds like an exaggeration to me.  If you care about those
characters, you should not have any difficulties realizing which are
identical and which aren't.  For several instances of the same
character, you need to type "C-u C-x =" just once.  So this is an
improvement vs the identical display of all the undisplayable
characters, where you must type "C-u C-x =" for each one of them.

If you don't care what those characters are, then you just don't need
to waste any time thinking what they could be and which ones are
different.  So here, there's no disadvantage to the current display.

>   >   What
>   > you saw before was a bug in the way Emacs detected which characters
>   > the Linux console is capable of displaying.
> 
> I am surprised.  I thought of the diamond display as a feature; ISTR
> we discussed it as such.  But maybe I'm mistaken.

You are mistaken.  It was never a feature.

> Either way, I'd much rather have the diamonds.

You can have any ASCII character (see above) or a string of characters
instead.  But not the diamond, which is a non-ASCII character.