bug#54970: 28.1; Some emoji no longer display

[Eli Zaretskii]

> From: Howard Melman <hmelman@gmail.com>
> Date: Sat, 16 Apr 2022 16:07:38 -0400
> Cc: alan@idiocy.org,
>  larsi@gnus.org,
>  54970@debbugs.gnu.org
> 
> > Your recipe didn't mention the U+FE0F codepoint.  You only talked
> > about the lone U+1F37D.  When followed by U+FE0F, Emacs indeed ought
> > to display the sequence as Emoji, and that should not require you to
> > change the font used for the 'symbol' pseudo-script.  Are you saying
> > that isn't happening in your case?
> 
> Indeed in Emacs 28 -Q if I
> 
> C-x 8 RET FORK AND KNIFE WITH PLATE RET
> C-x 8 RET FE0F RET
> 
> I see the emoji displayed.
> 
> If I use the system emoji selector to insert a character into emacs
> It only puts in "the lone U+1F37D" (at least in emacs where I can
> check). In other apps this displays as an emoji, in emacs it's a blank.

"Blank" meaning what?

Emacs should display the character if there's a font on the system
available to Emacs that has a glyph for that codepoint.  It just might
not display it as an Emoji, but as a slightly different symbol, and
usually with a different font and without the colors inherent in Emoji
display.  That's what happens on my system.  If that character doesn't
display at all for you, maybe your fonts don't support it?

The fundamental issue here is that some symbols have both an Emoji
presentation and a "text" presentation, and the VARIATION SELECTOR n
characters tell the rendering system which presentation to display.
The U+FE0F VARIATION SELECTOR 16 character tells Emacs to show the
Emoji presentation.  Without the variation selectors, Emacs displays
as Emoji only characters that are explicitly given the Emoji
presentation as the default by the Unicode Character Database files.
And AFAICT, U+1F37D is not one of them.

(Robert, please correct me if I'm wrong here.)

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

Emacs currently doesn't insert the variation selectors automatically,
although perhaps the Emoji input method should (or maybe already
does, I didn't check).

> I know this, in Emacs 27 macport I used C-x 8 RET and searched for plate
> and entered this character into a file and it displayed as an emoji.
> Several others I entered this way displayed fine too.  I upgraded to
> Emacs 28 and the other characters display fine and this one didn't.  
> I followed the instructions in NEWS and they didn't help.

Macport Emacs is a separate project that uses its own policies in
these somewhat gray areas.

> If the answer is just, this kind of emoji is different (though nothing else
> really exposes to it me as different), then I think the instructions (in NEWS
> or wherever) should just tell me to 
> 
> (set-fontset-font t 'symbol '("My New Emoji Font" . "iso10646-1") nil 
> 'prepend)
> 
> and not
> 
> (set-fontset-font t 'emoji '("My New Emoji Font" . "iso10646-1") nil 'prepend)

No, that wouldn't be right.  We introduced the special 'emoji'
pseudo-script in Emacs 28 to solve the problems of being unable to
distinguish between Emoji codepoints and the other symbols and
punctuation.  We definitely do NOT want to use an Emoji font for
symbols and punctuation characters and character sequences that aren't
Emoji.  Moreover, configuring the fontset to use some font for the
'symbol' pseudo-script by default doesn't do what you expect, because
Emacs uses the default font for symbols for which the default font has
a glyph.

So I think the recipe in NEWS is correct, and your expectations were
inconsistent with the Emacs support for Emoji, at least with its state
in Emacs 28.1.