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

Previous Next

Full log

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

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: Re: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F)
 where appropriate
Date: Fri, 26 May 2023 15:06:40 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: steven <at> stebalien.com,  63731 <at> debbugs.gnu.org
> Date: Fri, 26 May 2023 13:14:27 +0200
> 
>     >> Although the following is less invasive:
>     >> 
>     >> diff --git a/lisp/composite.el b/lisp/composite.el
>     >> index fb8b76114f4..333428f008a 100644
>     >> --- a/lisp/composite.el
>     >> +++ b/lisp/composite.el
>     >> @@ -762,6 +762,11 @@ compose-gstring-for-dotted-circle
>     >> (if (memq val '(Mn Mc Me))
>     >> (set-char-table-range composition-function-table key elt)))
>     >> unicode-category-table))
>     >> +  ;; for Emoji presentation selector
>     >> +  (set-char-table-range
>     >> +   composition-function-table
>     >> +   #xFE0F
>     >> +    `([,(purecopy "\\c.\ufe0f") 1 compose-gstring-for-graphic]))
>     >> ;; for dotted-circle
>     >> (aset composition-function-table #x25CC
>     >> `([,(purecopy ".\\c^") 0 compose-gstring-for-dotted-circle]))
> 
>     Eli> Can you please explain why the current setup doesn't work in this
>     Eli> case, even though "C-u C-x =" says the composition was done?  And how
>     Eli> the above patch fixes that?
> 
> Composition is done for 1f44d+fe0f, but I suspect that with the current
> setup, composition is called again for FE0F, which results in the box
> glyph. With the second patch we will only do backwards looking composition
> for FE0F

OK, then I think we should install this on the emacs-29 branch.

> Youʼre right, thereʼs no forward looking regexp, only a backwards one
> and a no-regexp. But itʼs undeniable that:
> 
>  [nil 0 compose-gstring-for-graphic]
> 
> causes the issue. Iʼve never been clear on the semantics of that.

It has special support in compose-gstring-for-graphic, see there.  The
doc string also says a few words about that.  We use this, e.g., in
describe-char display, where we sometimes need to show a single
combining character with no base character to combine it with.  I
think this is only relevant for accents and other such combining
characters, not for VS-n.

What does this issue mean for the other VS-n characters, though?
Should we perhaps install something similar for them as well?

Thanks.

Previous Next

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