Re: [PATCH] emoji on TUI emacs

>> 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?

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)?


=== Stefan