bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 63731@debbugs.gnu.org,  steven@stebalien.com
> Date: Tue, 30 May 2023 09:25:52 +0200
> 
> >>>>> On Mon, 29 May 2023 20:18:41 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> (set-char-table-range
>     Eli> composition-function-table
>     Eli> #xFE0F
>     Eli> '(["\\c.\ufe0f" 1 font-shape-gstring]))
>     >> 
>     Eli> so that we only see a composition if the font indeed agrees to
>     Eli> compose.  What do you see?
>     >> 
>     >> It still displays a single glyph with a thin-space. If I customize
>     >> `glyphless-char-display-control' to display hex codes for VS, then it
>     >> display a hex box.
>     >> 
>     >> So I guess that means weʼre not composing?
> 
>     Eli> What does "C-u C-x =" say in this case?
> 
> It claims itʼs composed:
> 
>              position: 146 of 251 (58%), column: 0
>             character: 👍 (displayed as 👍) (codepoint 128077, #o372115, 
> #x1f44d)
>               charset: unicode (Unicode (ISO10646))
> code point in charset: 0x1F44D
>                script: emoji
>                syntax: w      which means: word
>              category: .:Base
>              to input: type "C-x 8 RET 1f44d" or "C-x 8 RET THUMBS UP SIGN"
>           buffer code: #xF0 #x9F #x91 #x8D
>             file code: #xF0 #x9F #x91 #x8D (encoded by coding system 
> utf-8-unix)
>               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

Which means it _is_ composed.  Moreover, with Noto Color Emoji we get
a single glyph.  On my system, I have Noto Emoji, from which I get two
glyphs:

  [0 1 128077 422 17 1 15 12 2 nil]
  [0 1 65039 3 17 0 1 0 1 [0 0 0]]

(in which case I can understand why the second one is displayed as a
hex box if I customize glyphless-char-display-control).

So, given that this is the case, why is this wrong, again?  If the
font and the shaper produce two glyphs, or one glyph that looks like
two, why should we think it's an Emacs's problem?

(I verified that Emacs 28 shows the same, so this is not a recent
regression.)