Re: [PATCH] emoji on TUI emacs

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

> requires very good knowledge of how codepoint sequences combine in
> general and how Emacs handles that in particular.

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.

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


=== Stefan