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

[Eli Zaretskii]

> Date: Fri, 2 Sep 2022 16:12:12 +0000
> Cc: gregory@heytings.org, rms@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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.

I'm not sure there are other users.

> It really needs documenting somewhere, which might well be more
> work than just supplying an option.

The display-tables are documented already.  And we use them in quite a
few situations already, including in latin1-disp.el.

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

That's not what we call "support".

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

I'd welcome patches to do that, TIA.

> But I was more thinking about allowing the console itself to do the
> replacement with \ufffd.

There's no need to do that, since Emacs is capable of emitting that
character by itself.

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

It's just a loop calling char-displayable-p, that's all.  What's left
is for you to examine the results.

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

Just once.  So its scaling is O(1).  Literally.

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

For that, someone will have to figure out how to do that and submit
patches.  I don't know what else to suggest, since nothing seems to be
good enough.