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

Previous Next

Full log

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

From: Howard Melman <hmelman <at> gmail.com>
To: Robert Pluim <rpluim <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 10:35:17 -0400

> On Apr 17, 2022, at 9:34 AM, Robert Pluim <rpluim <at> gmail.com> wrote:
> 
>>>>>> On Sun, 17 Apr 2022 08:53:37 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>    Eli> The fundamental issue here is that some symbols have both an Emoji
>    Eli> presentation and a "text" presentation, and the VARIATION SELECTOR n
>    Eli> characters tell the rendering system which presentation to display.
>    Eli> The U+FE0F VARIATION SELECTOR 16 character tells Emacs to show the
>    Eli> Emoji presentation.  Without the variation selectors, Emacs displays
>    Eli> as Emoji only characters that are explicitly given the Emoji
>    Eli> presentation as the default by the Unicode Character Database files.
>    Eli> And AFAICT, U+1F37D is not one of them.
> 
>    Eli> (Robert, please correct me if I'm wrong here.)
> 
> Thatʼs exactly how it works. See
> <https://unicode.org/emoji/charts/emoji-style.html> for a listing of
> the affected codepoints and default styles.

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

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

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

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

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

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

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

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

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

>    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

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

Howard

Previous Next

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