Re: [PATCH] emoji on TUI emacs

> Date: Sat, 01 Aug 2026 11:16:31 -0400
> From: Stefan Monnier via "Emacs development discussions." <[email protected]>
> 
> >> Do you have other acceptable alternative solutions in mind?
> > Not at the moment, no.  But I'm open to ideas.  For example, we could
> > perhaps do better for Emoji sequences whose first codepoint has a
> > width of 2, by adding a padding glyphs.  But that's a partial solution
> > in any case.  And adding padding glyphs according to pixel_width of a
> > composite glyph is incorrect in general, because on text-mode frames
> > that value is in many cases incorrect.
> 
> AFAICT until terminal emulators provide ways to query them about the
> width of specific compositions there is no fully and automatically
> correct solution.  So how 'bout we do the next best thing: offer tools
> for users to fix the resulting breakage?
> 
> E.g. maybe we could have a Lisp-exposed database (alist,
> hash-table, younameit) that maps specific sequences of code points to
> their expected width on a specific terminal, and then we implement
> commands that users could use to update that database when they see
> a garbled screen?

I very much doubt users will be able to do that, since doing so
requires very good knowledge of how codepoint sequences combine in
general and how Emacs handles that in particular.

> Maybe also allow a more fine-grained control of auto-composition so it
> can be enabled for some compositions (which the user thinks work
> correctly, maybe with the help of the above manually-updated database) and
> disabled for others (which the user hasn't encountered yet or doesn't
> care to make work)?

This is not workable, IMO, because we have no way of telling the
terminal whether to compose or not to compose a given sequence of
codepoints.  We can perhaps tell that to Emacs, but the terminal will
do its thing regardless.

To have a complete solution, we need to have a way of asking the
terminal whether a given sequence of codepoints will be composed, and
if so, what will be the width of the result in character cell units.
I'm not aware of any protocol that satisfies these needs.