bug#54970: 28.1; Some emoji no longer display

[Robert Pluim]

>>>>> On Sun, 17 Apr 2022 10:35:17 -0400, Howard Melman <hmelman@gmail.com> 
>>>>> said:

    Howard> Thanks for all this info.  So on that page, in the second headed 
section of the 
    Howard> table "Emoji Font" is where U+1F37D appears.  In the "text-vs" row, 
which
    Howard> I think is the case of a lone U+1F37D, I see the emoji glyph in my 
mac browser.
    Howard> The description in that header says:

    Howard>   “text+ts” should be monochrome; everything else should be 
colorful & monospace.

    Howard> which matches what I see.  So I think, a lone U+1F37D should be 
displayed
    Howard> as an "emoji glyph".  

_If_ you've specified an emoji font for it, which we donʼt do by
default, since it has Emoji_Presentation = False, so you should look
at the "Plain" section instead.

    Howard> Can emacs be configured to display these lone codepoints via my 
emoji font?
    Howard> I gather that's what using the 'symbol script does but also 
includes more.
    Howard> Can I (or emacs out-of-the-box) be more selective in the call to 
    Howard> set-fontset-font or some other api?

Yes. Try:

(set-fontset-font t #x1f37d
    '("Apple Color Emoji" . "iso10646-1") nil 'prepend)

For a range of codepoints, replace #x1f37d with something like
'(#x1f37d . #x1f3aa)

    >>>> I said, I don't understand this stuff.  Is this extra codepoint 
supposed
    >>>> to be added for me?  It doesn't seem like other apps require it.
    >> 
    Eli> Emacs currently doesn't insert the variation selectors automatically,
    Eli> although perhaps the Emoji input method should (or maybe already
    Eli> does, I didn't check).
    >> 
    >> The stuff Lars added on master puts in variation selectors where
    >> needed.

    Howard> The emoji input method isn't on 28 so I can't check, but FWIW this 
seems
    Howard> to not match the behavior I see using the mac system emoji picker
    Howard> which seems to just insert a lone U+1F37D when I pick this emoji.

I donʼt think we should follow what the mac does when it contradicts
what Unicode is telling us.

    Howard> And I'll add, if that's displayed equivalently I'd prefer it, 
because I wouldn't
    Howard> have to deal with "extra invisible characters" after the glyph when
    Howard> using emacs editing commands (unless this is different behavior in 
29
    Howard> than in 28 when I add the variation selector character).

Those characters get composed, so they get treated as a single
unit. They really donʼt cause any problems.

    >> Modulo `use-default-font-for-symbols'

    Howard> FWIW this variable set to t for me which I think is the default.

I meant you should try setting it to 'nil'.

    Eli> So I think the recipe in NEWS is correct, and your expectations were
    Eli> inconsistent with the Emacs support for Emoji, at least with its state
    Eli> in Emacs 28.1.
    >> 
    >> Iʼm not sure what we could change. I guess we could add a
    >> configuration variable that says 'treat every code point that has a
    >> default text presentation and an emoji one as emoji', except we
    >> already have that: VARIATION SELECTOR 16

    Howard> I think the section I mentioned above is this case, that things in 
the
    Howard> "emojiFont" grouping, w/o a variation selector should be presented
    Howard> colorful and monospace (which I take to mean "as emoji").  Am I
    Howard> misunderstanding?

Again: when an emoji font has been specified for the codepoint.

Robert
--