> 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