Re: [PATCH] emoji on TUI emacs

> Date: Thu, 30 Jul 2026 17:03:58 +0200
> From: Kai Ma <[email protected]>
> 
> Today I took some time to look into the emoji problem on TUI emacs.
> There were some previous bug reports, for example, 79517, 81052.  This
> is a super annoying problem which makes it almost unusable to edit
> files containing emojis.  (Brief description: pressing C-n/C-p can
> cause duplicate rendered lines or empty lines, and it's not possible
> to clear it easily with C-l or redisplay.)

The way to make it possible to edit text with Emoji on text-only
frames is by disabling auto-composition-mode.  Did you try that?  If
you tried that, and you still find that "almost unusable", please tell
the details of what you see and preferably also show a simple recipe
to reproduce the problems you see.

> Previous discussions are usually about the width of a grapheme
> cluster.  But to my surprise, I found that the problem occurs even if
> the width is correct.  For example, ⚡ (#x26a1) composed with #fe0f
> has width 2,
> 
>      (string-width "\x26a1\xfe0f") ;; ==> 2

Yes, Emoji sequences which end in Variation Selector controls are one
of a couple of cases which currently cannot be correctly displayed on
text-only frames when auto-composition-mode is enabled.  Please try
disabling auto-composition-mode.

> and it still causes garbled lines.  Therefore, the incorrect width of
> an emoji is not the _only_ problem.

It isn't the width of the Emoji, it's the fact that

  (string-width "\x26a1") ;; ==> 2

IOW, adding the VS-15 control leaves the width unaltered.

> Upon further inspection, I'm
> pretty sure it's related to composition strings, and it's due to the
> wrong x index of the next glyph: even if the composition itself has
> pixel_width=2, the next glyph's index just increases by 1.  So this
> looks like a genuine problem.

Sorry, you lost me here: which code and in what function do you allude
here?

> Looking into the source code, in term.c, append_composite_glyph only
> appends one glyph, but in append_glyph, it appends pixel_width glyphs.
> Therefore, the attached patch simply copies the existing approach.  I
> have tested it on files containing many emojis, margins, and bidi
> texts, and observed no problems so far, but I might miss something so
> review is appreciated.

I don't understand why these changes are needed, or what is wrong with
the original code.

In general, it is wrong to produce as many glyphs as pixel_width for a
composite glyph, because Emacs cannot know the actual width of the
composed glyph on display, as shown on text-only frames.  The value of
pixel_width in this case is a guess based on what characters were
composed.  So your changes might work for some codepoints and on some
specific terminal emulators, but they will not work correctly in
general.

> Also, if it's considered a safe fix, is it possible to install this
> patch on emacs-31, considering how annoying the problem is?

Sorry, I don't think the changes are correct, let alone safe.  Please
try disabling auto-composition-mode instead.