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

[Eli Zaretskii]

> From: Aura Kelloniemi <kaura.dev@sange.fi>
> Cc: 50865@debbugs.gnu.org
> Date: Fri, 01 Oct 2021 16:23:01 +0300
> 
>  > > 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.
> 
> Can this be configured – i.e. can I change the space to something else to ease
> debugging?

Yes, see glyphless-char-display-control.

>  > 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?
> 
> Here is a sample Bash session for demonstration:
> $ echo $'i\u300'
> i◈
> $ echo $'\uEC'
> ì

Ouch!  What a terrible misfeature!

> If I set auto-composition-mode to nil, then Emacs does not print anything (not
> even the space) when I insert a combining character. If I then move the point
> over the invisible combining character, the point moves, but the screen cursor
> does not. This is a very confusing behaviour.

I think it's expected for accents.

> When running in the Linux console emacs's term/linux.el sets
> auto-composition-mode to a special value of "linux". I don't know what this
> means.

That is explained in the doc string of auto-composition-mode.

Does term/linux.el get loaded when you run Emacs on that terminal?