GNU bug report logs - #39799
28.0.50; Most emoji sequences don’t render correctly

Previous Next

Full log

Message #290 received at 39799 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: rgm <at> gnu.org, 39799 <at> debbugs.gnu.org, mfabian <at> redhat.com
Subject: Re: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Wed, 22 Sep 2021 16:47:39 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: rgm <at> gnu.org,  39799 <at> debbugs.gnu.org,  mfabian <at> redhat.com
> Date: Wed, 22 Sep 2021 10:59:00 +0200
> 
>     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.

We could probably lift this restriction if we change the logic in
composition_compute_stop_pos: it currently returns as soon as it finds
the first character with a valid entry in composition-function-table,
instead of keeping looking until it finds the one whose rule's PATTERN
starts at the smallest character position.  But even if it turns out
there are no problems with such a change, I wouldn't do it for Emacs 28.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.