From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 63731@debbugs.gnu.org, steven@stebalien.com
Subject: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate
Date: Mon, 29 May 2023 12:44:58 +0200 [thread overview]
Message-ID: <87edmzto0l.fsf@gmail.com> (raw)
In-Reply-To: <83353gipww.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 28 May 2023 15:47:11 +0300")
>>>>> On Sun, 28 May 2023 15:47:11 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: 63731@debbugs.gnu.org, steven@stebalien.com
>> Date: Sun, 28 May 2023 13:57:49 +0200
>>
>> Eli, if the 20e3 changes are too much for emacs-29, I can put them in
>> master.
Eli> Yeah, I think it should go to master for now.
I pushed the doc changes, but not the code changes, because I now
think theyʼre papering over a deeper bug (which weʼve noticed before,
but didnʼt fix then).
In all these cases, consider the sequence U+1F44D U+FE0F
- emacs-29:
Displays as colour emoji, followed by an empty box
- emacs-29 with the following change in composite.el:
(set-char-table-range
composition-function-table
#xFE0F
`([,(purecopy "\\c.\ufe0f") 1 compose-gstring-for-graphic]))
Displays as colour emoji. Much rejoicing. If I follow my own
advice, and customize `glyphless-char-display-control' to show
hex-boxes for variation selectors, you then see that in actual
fact, we are still displaying the FE0F, but since it uses
thin-space by default, it wasnʼt obvious. Much sadness.
C-u C-x =:
display: composed to form "👍️" (see below)
Composed with the following character(s) "️" using this font:
ftcrhb:-GOOG-Noto Color Emoji-regular-normal-normal-*-13-*-*-*-m-0-iso10646-1
by these glyphs:
[0 1 128077 569 16 0 17 13 4 nil]
with these character(s):
️ (#xfe0f) VARIATION SELECTOR-16
Now I notice (via emoji-variation-sequences.txt), that this is only
happening for the following codepoints.
U+1F408
U+1F415
U+1F426
U+1F446
U+1F447
U+1F448
U+1F449
U+1F44D
U+1F44E
And if I look in lisp/international/emoji-zwj.el, I find:
(#x1F44D .
,(eval-when-compile (regexp-opt
'(
"\N{U+1F44D}\N{U+1F3FB}"
"\N{U+1F44D}\N{U+1F3FC}"
"\N{U+1F44D}\N{U+1F3FD}"
"\N{U+1F44D}\N{U+1F3FE}"
"\N{U+1F44D}\N{U+1F3FF}"
))))
If I add
"\N{U+1F44D}\N{U+FE0F}"
to that, and undo the composite.el change, then everything is
fine. Hurrah! This means that the
`([,(purecopy "\\c.\\c^+") 1 compose-gstring-for-graphic]
[nil 0 compose-gstring-for-graphic])
is not doing the right thing for this case.
I can change the emoji-zwj.awk script to add CHAR+FE0F for all emoji,
unless someone knows how to fix composition to do the right thing
here.
(there are similar issues with CHAR+FE0E)
Robert
--
next prev parent reply other threads:[~2023-05-29 10:44 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-26 3:18 bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate Steven Allen
2023-05-26 6:41 ` Eli Zaretskii
2023-05-26 8:34 ` Robert Pluim
2023-05-26 8:46 ` Eli Zaretskii
2023-05-26 11:14 ` Robert Pluim
2023-05-26 12:06 ` Eli Zaretskii
2023-05-26 14:02 ` Robert Pluim
2023-05-26 14:55 ` Eli Zaretskii
2023-05-26 15:25 ` Robert Pluim
2023-05-26 15:52 ` Eli Zaretskii
2023-05-26 16:24 ` Robert Pluim
2023-05-26 17:27 ` Eli Zaretskii
2023-05-26 17:35 ` Robert Pluim
2023-05-26 18:05 ` Eli Zaretskii
2023-05-28 11:43 ` Robert Pluim
2023-05-28 12:44 ` Eli Zaretskii
2023-05-26 17:43 ` Eli Zaretskii
2023-05-28 10:29 ` Robert Pluim
2023-05-28 12:37 ` Eli Zaretskii
2023-05-28 11:57 ` Robert Pluim
2023-05-28 12:47 ` Eli Zaretskii
2023-05-29 10:44 ` Robert Pluim [this message]
2023-05-29 13:58 ` Eli Zaretskii
2023-05-29 14:43 ` Robert Pluim
2023-05-29 14:55 ` Eli Zaretskii
2023-05-29 16:13 ` Robert Pluim
2023-05-29 17:18 ` Eli Zaretskii
2023-05-30 7:25 ` Robert Pluim
2023-05-30 12:10 ` Eli Zaretskii
2023-05-30 13:30 ` Robert Pluim
2023-05-30 16:32 ` Eli Zaretskii
2023-05-31 16:11 ` Robert Pluim
2023-05-31 16:18 ` Eli Zaretskii
2023-06-01 12:43 ` Eli Zaretskii
2023-06-01 13:30 ` Robert Pluim
2023-06-01 16:10 ` Eli Zaretskii
2023-06-01 16:34 ` Robert Pluim
2023-06-02 8:15 ` Robert Pluim
2023-06-02 12:06 ` Eli Zaretskii
2023-06-02 12:25 ` Robert Pluim
2023-06-02 12:58 ` Eli Zaretskii
2023-06-02 13:58 ` Robert Pluim
2023-06-03 5:36 ` Eli Zaretskii
2023-06-05 13:08 ` Robert Pluim
2023-06-05 13:12 ` Eli Zaretskii
2023-06-05 13:31 ` Eli Zaretskii
2023-06-05 14:06 ` Robert Pluim
2023-06-05 13:36 ` Robert Pluim
2023-06-05 13:47 ` Eli Zaretskii
2023-06-05 14:27 ` Robert Pluim
2023-06-05 15:35 ` Eli Zaretskii
2023-06-05 15:57 ` Robert Pluim
2023-06-05 16:20 ` Robert Pluim
2023-06-05 16:41 ` Eli Zaretskii
2023-06-06 7:24 ` Robert Pluim
2023-06-05 16:39 ` Eli Zaretskii
2023-06-06 7:28 ` Robert Pluim
2023-06-06 11:53 ` Eli Zaretskii
2023-05-26 15:06 ` Steven Allen
2023-05-26 15:29 ` Robert Pluim
2023-05-26 16:03 ` Steven Allen
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=87edmzto0l.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=63731@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=steven@stebalien.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).