GNU bug report logs - #54970
28.1; Some emoji no longer display

Previous Next

Full log

Message #59 received at 54970 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Howard Melman <hmelman <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
 54970 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#54970: 28.1; Some emoji no longer display
Date: Sun, 17 Apr 2022 17:14:53 +0200

>>>>> On Sun, 17 Apr 2022 10:35:17 -0400, Howard Melman <hmelman <at> 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
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.