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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 28 Feb 2020 22:16:21 +0200

> From: Robert Pluim <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Fri, 28 Feb 2020 17:39:56 +0100
> 
> I donʼt think that applies in this case. The sequences are all easily
> categorised based on the first char in the sequence. It could be done
> based on the 2nd, or 3rd or whatever, but I donʼt think that reduces
> the number of entries. Plus thereʼs always one rule per character,
> since multiple patterns starting with the same character are combined
> using regexp-opt.

I wrote that to describe the general considerations, not necessarily
because I think they are applicable in this particular case.  I didn't
analyze the sequences to see whether any of what I wrote can or should
be used for them.

> One thing though: the code currently does set-char-table-range to a
> new value. Is there a chance that an entry already exists in
> composition-function-table for a particular character?

Only if the non-leading character is a combining character, which I
think is unlikely.  But in general, yes, this should be tested up
front to avoid losing composition rules.