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

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
>> Date: Fri, 26 Aug 2022 08:52:05 +0200
>> 
>> I can't find a way to tweak glyphless-char-display-control to let TTY
>> frames show diamonds again…  maybe a new value display method would be
>> needed for that purpose?
>
> The diamond is a non-ASCII character, so to display it by default,
> we'd need to make sure the terminal is capable of displaying it.
>
> Also, do you really mean diamond, or do you mean U+FFFD REPLACEMENT
> CHARACTER (which on GUI display is shown as a diamond with a question
> mark inside)?

Based on that past discussion, my assumption was that when Richard said
in his OP:

>              In Emacs 29, display of undisplayable characters has
> changed.  It used to show them with a diamond.

… he was referring to the diamond-like symbol that the Linux console
shows for glyphless characters (so not U+FFFD), and that Emacs (in a
TTY) used to show as well, until your patch which made these characters
fall into the 'no-font group, which means they are now displayed with
the 'hex-code method.

I tried to find out precisely what Unicode codepoint that symbol is
supposed to correspond to, if any, but haven't reached any conclusion.

> And why the diamond, of all the possible characters? why not simply
> '?', for example?

I'll let Richard answer that one, but I suspect any single-column
character would be fine: the problem, as I understand it, is that (1)
they are no more informative than a single placeholder char:

>                                              To find out what
> character a code represents, I have to use C-u C-x =, just as I did
> before.

… and (2) they make reading more difficult:

> I find that change quite inconvenient.  It makes the text harder to
> read.

I'm guessing Richard is faced with mostly-legible ASCII paragraphs with
just a couple of glyphless chars strewn within; then I'd imagine the hex
codes impair the reading experience more than single-column characters
(diamonds, '?', what-have-you).

*shrug* I don't live in a TTY, so I don't have an informed opinion on
what the most useful representation would be.  Off the top of my head,
I see

* a minimalist approach: add a new 'char method that lets you pick your
  favourite placeholder character for the 'no-font group,

* a maximalist approach: embark on a quest to add legible and
  informative display methods for every category that might be
  susceptible to lack glyphs[1].  (And allow to express these categories
  in glyphless-char-display-control… perhaps allowing GROUP to be a
  script symbol, like set-fontset-font's CHARACTERS argument?)

Can't speak for Richard, but I'm getting the sense the minimalist
approach would suit him just fine.


[1] E.g.

  * 'phonetic for international alphabets (sort of the opposite of an
    input method like cyrillic-translit, a table that would map ?я to
    "ja", ?ш to "sh"),
  * 'cldr for emoji (?😀 → "*grinning face*"), or 'smiley (?🙌 → \o/),
  * 'tex for symbols (?↦ → "\mapsto"), …