bug#54970: 28.1; Some emoji no longer display

[Howard Melman]

On Apr 17, 2022, at 1:53 AM, Eli Zaretskii <eliz@gnu.org> wrote:

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?

Blank as I described in my original report where I included the output
of C-u C-x = which does say there's no font available.  Following the 
recipe with point before the added character it looks like this:

with point after the character it looks like this:

On the macport I see tofu which I think is better.

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

I realize.  I originally report this there because it did previously handle

emoji better on mac but as of Emacs 28, it's NEWS says:

    Emoji composition handling is aligned with upstream.  You may find
    some incompatibilities with the previous versions.

In email, YAMAMOTO Mitsuharu said to me about this:

"I only mentioned composition, but font selection is also affected."

When I confirmed it was not displayed by the NS port either I reported

it here.

So FYI, I think in this area the macport policies are trying to

converge with Emacs' policies, though I don't want to speak for them.

Howard