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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: mfabian@redhat.com,  rgm@gnu.org,  39799@debbugs.gnu.org
> Date: Tue, 21 Sep 2021 18:10:37 +0200
> 
> >>>>> On Tue, 21 Sep 2021 18:58:38 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> Because for skin tones we index on the modifier, and use lookback:
>     >> 
>     >> ;; Skin tones
>     >> (set-char-table-range composition-function-table
>     >> '(#x1F3FB . #x1F3FF)
>     >> (nconc (char-table-range composition-function-table '(#x1F3FB . 
> #x1F3FF))
>     >> (list (vector ".[\U0001F3FB-\U0001F3FF]"
>     >> 1
>     >> 'compose-gstring-for-graphic))))
> 
>     Eli> Ah, okay.  But why isn't that working?
> 
> I have no idea. Even a single entry for U+1F469 in
> composition-function-table in emoji-zwj.el messes things up.

This rang a bell, so I looked around.  And sure enough, there's this
subtlety documented in the doc string of composition-function-table:

  The element at index C in the table, if non-nil, is a list of
  composition rules of the form ([PATTERN PREV-CHARS FUNC] ...);
  the rules must be specified in the descending order of PREV-CHARS
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  values.
  ^^^^^^

(I could find the code which enforces this, if necessary, but I
clearly remember bumping into this in misc-lang.el, with Arabic
composition rules, which is when I added the above to documentation.)

And emoji-zwj.el doesn't adhere to this condition.  If you reorder the
rules as required above, does the problem go away (I cannot test this
myself, as I don't have access to a system where color Emoji work in
Emacs)?

>     Eli> Are you debugging this, or would you like me to take a look?
> 
> Iʼd appreciate it if you have time. Itʼs not code Iʼm very familiar
> with (and someone asked me to implement VS-16 based composition, so
> Iʼm busy :-) )

If the above doesn't work, I will dig more.