GNU bug report logs - #63731
[PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63731 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate
Date: Mon, 29 May 2023 12:44:58 +0200

>>>>> On Sun, 28 May 2023 15:47:11 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: 63731 <at> debbugs.gnu.org,  steven <at> 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
-- 

Previous Next

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