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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 2 Sep 2022 13:39:51 +0000
> Cc: gregory@heytings.org, rms@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > I agree with Richard that there should be an option for displaying
> > > characters outside of the current font as "�" rather than "\u2022".
> 
> > I already explained how to set that up, so what exactly does the
> > "should be" part here want to say?
> 
> The way you explained involves hacking Lisp

It involves writing some Lisp code and running it on your system,
yes.  How is that a problem?

> and finding out precise character ranges.  That's a lot different
> from being able just to set an option.

How can Emacs know which characters does your Linux console actually
support, out of all the Unicode range?  And how can Emacs know which
ones of those you want to see as their ASCII "emulations" (per
latin1-disp.el) and which you want to see as U+FFFD replacements?

So yes, this requires you, the user, to tell Emacs which ones you want
to see in what manner.  There are a lot of Unicode characters, so it
could be a large job, if the characters actually supported by the
console are all in distinct Unicode blocks.  (But if you only want to
see Latin-1 characters, I've shown in this thread a one-liner to do
that.  I guess you will reject that as well.)

> > There is already such a way in Emacs.  Just use it, if that's what you
> > want.
> 
> There appears to be no easy way to get the old behaviour back, where
> characters undisplayable on the console got displayed with \ufffd
> instead.  You've characterised this old behaviour as a bug, but in the
> preferences of two actual Linux console users (Richard and myself), the
> solution is not better than the bug.

I don't understand why you are consistently rejecting every solution
that was suggested.  Including, amazingly enough, a way to actually
produce the same "diamond" glyphs on display under the same
circumstances.  Since when do veteran Emacs hackers such as you and
Richard consider some Lisp coding a problem so grave as to justify
flatly rejecting it?

Please understand: you are _really_ using Emacs on a terminal that is
unsuitable for it.  You _should_ expect problems.  And when solutions
are pointed out that are just a few lines of Lisp away, I'd expect you
to embrace them, not flatly reject them.

> Have there been any untoward effects reported, by sending valid
> Unicode strings of bytes to the Linux console?

Sorry, but I don't care.  We will not send unsupported byte sequences
to any terminal, not if I have anything to say about that.  That's
simply bad engineering.  We have plenty of better, safer solutions.