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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Sep 02, 2022 at 16:59:48 +0300, Eli Zaretskii wrote:
> > 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?

It's not a problem for me, but might well be for other Linux console
users.  It really needs documenting somewhere, which might well be more
work than just supplying an option.

> > 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?

The console supports ALL characters in the Unicode range.  Most of them
it displays with the replacement character glyph, but it supports them
all in the important sense of not crashing, or going unresponsive, or
anything else like that.

> 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?

It could examine the currently loaded font, if needed.  But I was more
thinking about allowing the console itself to do the replacement with
\ufffd.

> 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.)

Some of the characters in my font lie outside the Latin-1 range.  Doing
this job properly requires writing some sort of script to examine the
loaded font.  I don't know how easy that would be.

> > > 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.

Every solution suggested is either a lot of work, or is less good than
how things were.

> 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?

It doesn't scale.  Without some sort of script, such as I suggested
above, it has to be hacked individually for each setup.

> Please understand: you are _really_ using Emacs on a terminal that is
> unsuitable for it.

For me, there is no better setup that I'm aware of.  If there were, I
would use 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.

I would prefer a solution that would work for all Linux console users,
including those who can't or don't want to hack Lisp.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).