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

[Eli Zaretskii]

> Date: Sun, 4 Sep 2022 11:23:43 +0000
> Cc: rms@gnu.org, gregory@heytings.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > A few days ago you said it could use char-displayable-p
> > > to determine this.  If that works, it solves the problem of finding out
> > > which characters to display as diamond.
> 
> > It works, but looping over all the Unicode characters is very slow, so
> > doing that at each startup would be unacceptable.  If someone needs, I
> > can show a simple code to be run by the user, once, on the Linux
> > console, that would allow then to determine the codepoint ranges for
> > which the U+FFFD (or any other) replacements are needed, so that users
> > could run that code, and then put such customizations in their init
> > files.  We could even have a special command to do that, if people
> > think it's important and helpful.
> 
> > But all I hear till now is flat rejection of that solution, which is a
> > very weak incentive (to say the least) to work on such a command.
> 
> I will start working on this soon (if nobody else does in the meantime).

No need, it's already done.  See the new command
standard-display-by-replacement-char.

> I envisage having a minor mode specific to the Linux console, which when
> enabled for the first time will do the loop over all Unicode characters
> testing them for glyps, and create the display table.

This loop takes a long time (25 sec in my unoptimized build, likely 5
sec in optimized ones), and needs to be run only once on a given
terminal.  So instead the command I added produces a buffer with Lisp
code that you could eval and also add to your init file, to be run
every startup.

> This can then be
> stored in .emacs in the customisation section.  When the mode is
> enabled, this display table will be used to output the \ufffd's.  When
> disabled, the glyphless characters will get printed as hex strings, as
> currently.  Possibly this will involve having two display tables which
> will get swapped when the mode is en/disabled.  Or something like that.

I don't really see a reason to reset the display table to its default
state, especially since it isn't clear what is that default.  E.g.,
the startup code could add a few entries in the display-table (to show
the Help buffers), as does info.el.  You don't want to lose those
setting, and there's no easy way of discerning them from the ones
produced by the command we are discussing.