bug#39799: 28.0.50; Most emoji sequences don’t render correctly

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Tue, 21 Sep 2021 21:20:07 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Tue, 21 Sep 2021 19:50:00 +0300
    >> From: Eli Zaretskii <eliz@gnu.org>
    >> Cc: rgm@gnu.org, 39799@debbugs.gnu.org, mfabian@redhat.com
    >> 
    >> I will take a look at the code.

    Eli> AFAICT, the composition machinery doesn't allow to have a rule with
    Eli> non-zero PREV-CHARS where PREV-CHARS are supposed to match characters
    Eli> that have their own rules in composition-function-table.  Such rules
    Eli> are never considered, because once the rules for a character are
    Eli> processed, we never reconsider what to do with that character.  I will
    Eli> ask Kenichi Handa whether my conclusion is indeed correct, but for
    Eli> now, I think we should take the fire escape you mentioned earlier:

OK. Those are surprising semantics. If it does turn out to be like
that, we should document it.

    >> >> Iʼve just tried adding "\N{U+1F469}\N{U+1F3FE}" to the composition
    >> >> function table regexp for U+1F469 manually, and now I get correct
    >> >> composition. That means we could process the
    >> >> RGI_Emoji_Modifier_Sequence entries from emoji-sequences.txt with
    >> >> emoji-zwj.awk and add them, indexed on the base character (and remove
    >> >> the above code).
    >> >>
    >> 
    >> This turns out to be a pretty small change, so if we donʼt get to the
    >> bottom of it we have an alternative.

    Eli> AFAIU, this means we will add 1F3FB..1F3FF to the characters that can
    Eli> follow each of those which have rules with zero lookback.

Yes. I won't get to that today though.

Robert
--