From: Howard Melman <hmelman@gmail.com>
To: Robert Pluim <rpluim@gmail.com>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
54970@debbugs.gnu.org, Alan Third <alan@idiocy.org>
Subject: bug#54970: 28.1; Some emoji no longer display
Date: Sun, 17 Apr 2022 14:44:25 -0400 [thread overview]
Message-ID: <8BFFC4B1-1FB3-421D-8377-376108A57905@gmail.com> (raw)
In-Reply-To: <87wnfn213m.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4670 bytes --]
> On Apr 17, 2022, at 11:14 AM, Robert Pluim <rpluim@gmail.com> wrote:
>
>>>>>> On Sun, 17 Apr 2022 10:35:17 -0400, Howard Melman <hmelman@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,
Ok, so you find out that U+1F37D has Emoji_Presentation = False from
http://www.unicode.org/Public/emoji/1.0//emoji-data.txt
which indicates the default presentation should be text:
1F37D ; text ; L2 ; none ; w # V7.0 (🍽) FORK AND KNIFE WITH PLATE
> so you should look at the "Plain" section instead.
Ok, looking in the plain section under text-vs on macos 11.6.5 in Safari
I see an emoji glyph there too for U+1F37D. This is the plain section
and U+1F37D is at the end of the top row in this image. There are a lot
of emoji shown in that section but less than in the emojiFont section.
>
> 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)
Thanks, doing these definitely gets me further to where I'd like:
(set-fontset-font t '(#x1F170 . #x1F6F3) '("Apple Color Emoji" . "iso10646-1") nil 'prepend)
(set-fontset-font t '(#x2139 . #x3299) '("Apple Color Emoji" . "iso10646-1") nil 'prepend)
I'm still confused as to why the above works but this didn't:
(set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend)
And I as I look at script-representative-chars, emoji is defined to be (emoji 127744 128512)
which I think means the hex range x1F300 - x1F600 so shouldn't include x1f37d?
Or does it not because the default expression is text? And if so how is that
factored into the emoji script symbol passed to set-fontset-font, I don't see
how that's defined other than as this range. And when I specify a range
directly I get my pretty glyph displayed.
> I donʼt think we should follow what the mac does when it contradicts
> what Unicode is telling us.
I certainly agree with this. I see that
https://unicode.org/reports/tr51/#Emoji_Implementation_Notes
says:
• only fully-qualified emoji zwj sequences should be generated by keyboards and other user input devices.
and working through the definition of fully-qualified emoji
https://unicode.org/reports/tr51/#def_fully_qualified_emoji
a lone U+1F37D is not fully-qualified.
If I understand emacs' state correctly, insert-char is doing the right thing
because it's just inserting a character. I think I'm picking an emoji but
I'm not really, I'm picking a single character (in this case U+1F37D).
A later Emacs will have an emoji input method that would
be like a real emoji picker that lets me insert a proper fully-qualified sequence.
> 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.
Well C-f and C-b seem to move point between them which is somewhat startling.
>>> 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'.
In an emacs -Q in the scratch buffer I inserted a lone U+1F37D
Toggling use-default-font-for-symbols had no effect on its display.
Even after I did:
(set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend)
Howard
[-- Attachment #2.1: Type: text/html, Size: 8164 bytes --]
[-- Attachment #2.2: Screen Shot 2022-04-17 at 12.01.23 PM.png --]
[-- Type: image/png, Size: 237089 bytes --]
next prev parent reply other threads:[~2022-04-17 18:44 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-16 13:07 bug#54970: 28.1; Some emoji no longer display Howard Melman
2022-04-16 14:18 ` Lars Ingebrigtsen
2022-04-16 14:55 ` Lars Ingebrigtsen
2022-04-16 15:27 ` Howard Melman
2022-04-16 16:02 ` Alan Third
2022-04-16 16:21 ` Howard Melman
2022-04-16 16:42 ` Eli Zaretskii
2022-04-16 17:17 ` Howard Melman
2022-04-16 18:26 ` Eli Zaretskii
2022-04-16 19:19 ` Howard Melman
2022-04-16 19:22 ` Eli Zaretskii
2022-04-16 20:07 ` Howard Melman
2022-04-17 5:53 ` Eli Zaretskii
2022-04-17 13:34 ` Robert Pluim
2022-04-17 14:35 ` Howard Melman
2022-04-17 15:14 ` Robert Pluim
2022-04-17 18:44 ` Howard Melman [this message]
2022-04-17 18:49 ` Lars Ingebrigtsen
2022-04-17 18:56 ` Howard Melman
2022-04-17 18:58 ` Eli Zaretskii
2022-04-17 19:40 ` Howard Melman
2022-04-17 22:03 ` Howard Melman
2022-04-18 5:12 ` Eli Zaretskii
[not found] ` <0AC9BAB0-35AA-4088-BEEB-66D5B0459FC2@gmail.com>
2022-04-18 13:19 ` Howard Melman
2022-04-22 21:56 ` Howard Melman
2022-04-23 7:51 ` Eli Zaretskii
2022-04-23 16:35 ` Howard Melman
2022-04-23 16:58 ` Eli Zaretskii
2022-04-23 17:22 ` Howard Melman
2022-04-23 17:46 ` Eli Zaretskii
2022-04-23 19:12 ` Howard Melman
2022-04-23 9:46 ` Eli Zaretskii
2022-04-17 14:35 ` Howard Melman
2022-04-17 14:44 ` Eli Zaretskii
2022-04-17 14:50 ` Howard Melman
2022-04-17 15:50 ` Eli Zaretskii
2022-04-17 15:54 ` Howard Melman
2022-04-17 16:17 ` Eli Zaretskii
2022-04-17 16:48 ` Howard Melman
2022-04-17 18:00 ` Eli Zaretskii
2022-04-17 18:09 ` Howard Melman
2022-04-17 18:27 ` Lars Ingebrigtsen
2022-04-17 18:36 ` Eli Zaretskii
2022-04-17 18:45 ` Lars Ingebrigtsen
2022-04-17 18:54 ` Howard Melman
2022-04-17 18:58 ` Eli Zaretskii
2022-04-17 19:27 ` Alan Third
2022-04-17 19:47 ` Alan Third
2022-04-17 20:34 ` Alan Third
2022-04-17 21:05 ` Howard Melman
2022-04-18 4:29 ` Eli Zaretskii
2022-04-18 13:19 ` Alan Third
2022-04-18 14:23 ` Eli Zaretskii
2022-04-18 19:28 ` Alan Third
2022-04-19 1:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-19 3:51 ` Alan Third
2022-04-17 18:34 ` Eli Zaretskii
2022-04-17 18:46 ` Howard Melman
2022-04-17 19:00 ` Eli Zaretskii
2022-04-17 19:47 ` Howard Melman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8BFFC4B1-1FB3-421D-8377-376108A57905@gmail.com \
--to=hmelman@gmail.com \
--cc=54970@debbugs.gnu.org \
--cc=alan@idiocy.org \
--cc=larsi@gnus.org \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).