Re: scratch/emoji vs emacs that maybe canʼt display emojis

[Robert Pluim]

>>>>> On Fri, 05 Nov 2021 16:25:16 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org
    >> Date: Fri, 05 Nov 2021 14:38:41 +0100
    >> 
    Eli> Does it behave correctly wrt the display width of the displayed Emoji?
    Eli> That is, does string-width agree with the number of columns the
    Eli> displayed Emoji takes on the screen?
    >> 
    >> No, string-width gives 2, it actually takes up 1 column, which is
    >> unexpected for a non-composed character.

    Eli> This means you will have a messed-up display.

Eventually, yes. I can live with that for this specific case.

    >> >> On macos, in gui frames, I see similar issues until I cherry-pick
    >> >> e3171e7e86, which says to me thereʼs an issue with the 'can I display
    >> >> this codepoint' code.
    >> 
    Eli> Indeed, how can we know that a particular TTY frame can display Emoji?
    Eli> For a single character, we have a more-or-less reliable method, but
    Eli> for a composable sequence?
    >> 
    >> Well, this is a single character Iʼm trying to enter. And even if
    >> Emacs canʼt display the codepoints, it shouldn't break the transient.

    Eli> With a single character it's supposed to work.  Where exactly does it
    Eli> break? can you show the code?

I know nothing about transient. I suspect that when I get to the third
level of the transient, because the entries are all single codepoints
or grapheme clusters the generated transient is empty, since none of
them can be displayed (unlike the first 2 levels, which contain
categories of emojis).

Robert
--