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

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Mon, 29 May 2023 16:58:43 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> display: composed to form "👍️" (see below)

    Eli> This is not what I see.  I didn't use the above set-char-table-range
    Eli> expression literally, but instead started "emacs -Q", and then
    Eli> evaluated in *scratch*:

    Eli>       (set-char-table-range
    Eli>        composition-function-table
    Eli>        #xFE0F
    Eli>        '(["\\c.\ufe0f" 1 compose-gstring-for-graphic]))

    Eli> After that, the sequence U+1F44D U+FE0F displays as a single glyph,
    Eli> and there's no thin space after it.  What am I missing?  Is this
    Eli> somehow specific to ftcrhb font driver or something?

Itʼs a single glyph, but that glyph contains a thin-space. I used this
to check, the second 'a' is slightly offset

👍️a
👍a

This persists if I disable harfbuzz, and it behaves the same on macOS

    Eli> You are saying that the entry in composition-function-table for
    Eli> U+1F44D (and other similar characters) is used in preference to the
    Eli> entry for U+FE0F that follows it, even though there's no U+1F3FB
    Eli> etc. after it to "steal" the composition?  Did you try stepping
    Eli> through composite.c to see whether and why this is the case?

Right. It looks the the FE0F entry is ignored. Iʼve not ventured into
composite.c yet.

    >> 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.

    Eli> I think we need first to understand the issue at hand better.  There's
    Eli> more here than meets the eye, I think.

Absolutely

Robert
--