[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles e
From: |
Eli Zaretskii |
Subject: |
bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display |
Date: |
Wed, 29 Sep 2021 16:00:22 +0300 |
> From: Aura Kelloniemi <kaura.dev@sange.fi>
> Cc: 50865@debbugs.gnu.org
> Date: Tue, 28 Sep 2021 23:32:53 +0300
>
> On 2021-09-28 at 21:35 +0300, Eli Zaretskii <eliz@gnu.org> 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.
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display, Aura Kelloniemi, 2021/09/28
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display, Eli Zaretskii, 2021/09/28
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display, Aura Kelloniemi, 2021/09/28
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display, Eli Zaretskii, 2021/09/28
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display, Aura Kelloniemi, 2021/09/28
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display, Eli Zaretskii, 2021/09/28
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display, Aura Kelloniemi, 2021/09/28
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display, Aura Kelloniemi, 2021/09/28
- bug#50865: 28.0.50; Emoji with emoji modifier in Linux console garbles emacs display,
Eli Zaretskii <=