GNU bug report logs - #54562
28.0.91; Emoji sequence not composed

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: luangruo <at> yahoo.com, rpluim <at> gmail.com, 54562 <at> debbugs.gnu.org
Subject: bug#54562: 28.0.91; Emoji sequence not composed
Date: Fri, 25 Mar 2022 16:44:17 +0300

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: luangruo <at> yahoo.com,  rpluim <at> gmail.com,  54562 <at> debbugs.gnu.org
> Date: Fri, 25 Mar 2022 14:14:27 +0100
> 
> On Mär 25 2022, Eli Zaretskii wrote:
> 
> > By which composition rule?  Isn't that because U+20E3 is a combining
> > character?
> 
> Sure.  If Emacs were able to do that even if the default does not
> contain U+20E3 that would be ideal.  Or if Emacs were able to combine a
> and U+0308 even if the latter is not avaliable in the default font.

I think Emacs only considers the font of the base character when it
tries to compose?  So even if I do

  (set-fontset-font t #x20e3 '("Symbola" . "iso10646-1") nil 'prepend)

there's no composition between '7' and U+20E3.

(This does work with Emoji sequences, but AFAIR that's because we have
an extra-special hack in composite.c for characters that are in
auto-composition-emoji-eligible-codepoints.)

Previous Next

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