Re: [PATCH] emoji on TUI emacs

> From: Stefan Monnier <[email protected]>
> Cc: [email protected]
> Date: Sun, 02 Aug 2026 10:04:42 -0400
> 
> >> 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
> 
> I was looking at it as a challenge on the part of the one writing the
> command that updates the database, rather than on the art of the users.

"A Lisp-exposed database" made me think you have in mind a data
structure that users should manage "by hand".

> I was hoping we can provide a command that takes care of those details.
> E.g. a command that asks the user to put the cursor on the "last position
> that's still displayed at the right place" (LKGP), then move the cursor by one
> (composed) position and ask the user what they see, then do a tentative
> update of the database, ask again the user what they see, ...
> 
> Or insert a line of ASCII the text above the LKGP and ask the user which
> char in the line is immediately above position N (a position shortly
> after the LKGP) in order to guess what to add to the database.

Sounds like a tedious UI to me.

This discussion seems to point out easier solutions, at least in a
majority of cases.

> >> 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.
> 
> Then how come disabling auto-composition "works"?

It causes Emacs assumptions be correct in many more cases than the
other state.  Especially with Emoji sequences.