[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54970: 28.1; Some emoji no longer display
From: |
Howard Melman |
Subject: |
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@gmail.com> wrote:
>
>>>>>> On Sun, 17 Apr 2022 08:53:37 +0300, Eli Zaretskii <eliz@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
- bug#54970: 28.1; Some emoji no longer display, (continued)
- bug#54970: 28.1; Some emoji no longer display, Alan Third, 2022/04/16
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/16
- bug#54970: 28.1; Some emoji no longer display, Eli Zaretskii, 2022/04/16
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/16
- bug#54970: 28.1; Some emoji no longer display, Eli Zaretskii, 2022/04/16
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/16
- bug#54970: 28.1; Some emoji no longer display, Eli Zaretskii, 2022/04/16
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/16
- bug#54970: 28.1; Some emoji no longer display, Eli Zaretskii, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display, Robert Pluim, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display,
Howard Melman <=
- bug#54970: 28.1; Some emoji no longer display, Robert Pluim, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display, Lars Ingebrigtsen, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display, Eli Zaretskii, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/17
- bug#54970: 28.1; Some emoji no longer display, Eli Zaretskii, 2022/04/18
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/18
- bug#54970: 28.1; Some emoji no longer display, Howard Melman, 2022/04/18