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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, gregory@heytings.org, emacs-devel@gnu.org
> Date: Fri, 02 Sep 2022 22:51:26 -0400
> 
> Eli said it would be difficult to reliably display undisplayable
> characters as diamond _on all consoles_.  But I contend that it is not
> hard to implement an option to do this _on Linux consoles_.
> Eli, is there something difficult about that?

Yes: I know of no way of identifying such a console except by its
name.  And hard-coding a name of a specific console into our code is
inelegant at best.  Worse, AFAIU, when people use fbterm, which
doesn't have these problems, the name of the console reported to Emacs
is sometimes also "linux", so we already see, even in this relatively
short discussion, the difficulties with using the name as the unique
identifier for this purpose.

More generally, I have no reason to believe that the "feature" of the
Linux console whereby it accepts _any_ UTF-8 encoded character and
displays the U+FFFD "diamond" replacement for those it has no glyphs,
is rock-solid enough.  Someone said that the Linux console only knows
about Unicode 5.0 and older; we are going to see Unicode 15.0 in a few
days, where there are many more characters.  To say nothing of the
Emacs's own extensions of the Unicode code-space.  These are shaky
grounds to build upon, since none of the people who are talk,ing here
in favor of such a "solution" are actual maintainers of the Linux
console, and none of actual maintainers have spoken in this
discussion.

Moreover, a safer method to get the same effect exists, and was
described here.  It just needs some user configuration, which
unfortunately only users can do, because the Linux console (AFAIU) can
be configured to use different fonts, and thus the characters it is
capable of displaying correctly cannot be known by Emacs in advance.

> This option doesn't need to go through terminfo, if that would make
> it difficult.

This kind of kludgey features leads to code that is harder to
maintain, so I'd like to avoid doing so if better ways exist.  And
they do in this case.