Subject: Re: bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display

From: Eli Zaretskii <[email-masked]>
Date: Wed, 29 Sep 2021 16:00:22 +0300

> From: Aura Kelloniemi <[email-masked]>
> Cc: [email-masked]
> Date: Tue, 28 Sep 2021 23:32:53 +0300
> 
> On 2021-09-28 at 21:35 +0300, Eli Zaretskii <[email-masked]> wrote:
>  > That should not be that way.  Some characters are double-width, and
>  > should take up 2 columns on display.
> 
> I noticed, that Linux console does not understand most of the zero-width
> characters either.

It doesn't need to: Emacs displays those characters on a TTY as
spaces.

> It happily prints most of the code points in the list of
> zero-width characters. Of course they are printed just as diamonds, because
> Linux cannot store enough glyphs in its 512-glyph font space, but anyway it
> prints a diamond for such characters as <COMBINING GRAVE ACCENT>.

COMBINING GRAVE ACCENT (or any other combining codepoint) is not a
good example of zero-width characters.  Try "C-x 8 RET 200c RET"
instead.  Or FEFF or 1D173 or E007f or 1BCA0.

> The character range \y200B-\u200F seems to be an exception here. When I try to
> print one of these characters on a Linxu VT, it really prints nothing.

That's not exception, that's the rule, actually, for true zero-width
characters, not for accents.  Accents exist to combine with preceding
base character, and what you seem to describe means the Linux console
is unable to do even Latin accents?

> When I insert zero-width characters in Emacs, the diamonds representing the
> characters are printed interspersed by the padding spaces added by emacs. The
> cursor is left behind the extending line of characters as a type, because
> Emacs thinks, that the zero-width characters really do not print anything,
> even though they do.

Is this with or without auto-composition-mode?

> I believe that the one viable solution is to make char-width-table a terminal
> local variable, so that there can be a simplified version for terminals that
> don't understand Unicode correctly.

That would affect much more than display, because Emacs consults that
table for other purposes.  We need something limited to display alone.