GNU bug report logs - #63731
[PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate

Previous Next

Package: emacs;

Reported by: Steven Allen <steven <at> stebalien.com>

Date: Fri, 26 May 2023 03:19:01 UTC

Severity: normal

Tags: fixed, patch

Fixed in version 29.1

Done: Robert Pluim <rpluim <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 63731 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate
Date: Tue, 06 Jun 2023 14:53:41 +0300
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 63731 <at> debbugs.gnu.org,  steven <at> stebalien.com
> Date: Tue, 06 Jun 2023 09:28:04 +0200
> 
> >>>>> On Mon, 05 Jun 2023 19:39:37 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> Cc: 63731 <at> debbugs.gnu.org,  steven <at> stebalien.com
>     >> Date: Mon, 05 Jun 2023 17:57:04 +0200
>     >> 
>     >> >>>>> On Mon, 05 Jun 2023 18:35:37 +0300, Eli Zaretskii <eliz <at> 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.

I don't think it could break, since such sequences are all likely to
be triggered by special codepoints that follow the U+2xxx characters.
Our win would be a much simpler setup.

But okay, let's try to do it this way.




This bug report was last modified 1 year and 350 days ago.

Previous Next


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