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

[Robert Pluim]

>>>>> On Mon, 05 Jun 2023 19:39:37 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: 63731@debbugs.gnu.org,  steven@stebalien.com
    >> Date: Mon, 05 Jun 2023 17:57:04 +0200
    >> 
    >> >>>>> On Mon, 05 Jun 2023 18:35:37 +0300, Eli Zaretskii <eliz@gnu.org> 
said:
    >> 
    Eli> Which forward rules would conflict with a backward rule triggered by
    Eli> U+FE0E?
    >> 
    >> All the ones for the non-emoji codepoints that still need to be
    >> composed as emoji sometimes, eg U+261D:
    >> 
    >> "\N{U+261D}"
    >> "\N{U+261D}\N{U+1F3FB}"
    >> "\N{U+261D}\N{U+1F3FC}"
    >> "\N{U+261D}\N{U+1F3FD}"
    >> "\N{U+261D}\N{U+1F3FE}"
    >> "\N{U+261D}\N{U+1F3FF}"

    Eli> Couldn't we put these in the slots of #x1F3FB..#x1F3FF instead, as
    Eli> backward rules?  As long as we don't have a forward rule starting with
    Eli> #x261D, we could have backward rules for it triggered by #x1F3Fx and
    Eli> #xFE0x, right?

Yes, we could invert the whole composition rules setup, and make them
all work backwards, but then it will almost certainly all break again
with the next release of Unicode. Adding a special case for FE0E in
font_range is going to be more robust.

Robert
--