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

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54562 <at> debbugs.gnu.org
Subject: bug#54562: 28.0.91; Emoji sequence not composed
Date: Fri, 25 Mar 2022 18:32:08 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> I think this means your default font doesn't support the U+20E3
> COMBINING ENCLOSING KEYCAP character.  Emacs cannot compose characters
> that aren't supported by the font used for the base character.  Here's
> what I see in "C-u C-x =" on my system, when Emacs uses a font that
> does support it (and where I do see "7" inside a square):
>
> 	       position: 148 of 150 (98%), column: 2
> 	      character: 7 (displayed as 7) (codepoint 55, #o67, #x37)
> 		charset: ascii (ASCII (ISO646 IRV))
>   code point in charset: 0x37
> 		 script: latin
> 		 syntax: w 	which means: word
> 	       category: .:Base, a:ASCII, l:Latin, r:Roman
> 	       to input: type "C-x 8 RET 37" or "C-x 8 RET DIGIT SEVEN"
> 	    buffer code: #x37
> 	      file code: #x37 (encoded by coding system iso-latin-1-dos)
> 		display: composed to form "7⃣️" (see below)
>
>   Composed with the following character(s) "⃣️" using this font:
>     harfbuzz:-outline-Symbola-normal-normal-normal-serif-16-*-*-*-p-*-iso8859-1
>   by these glyphs:
>     [0 2 55 26 8 0 7 11 0 nil]
>     [0 2 8419 2327 0 -10 4 10 4 nil]
>     [0 2 65039 3 4 0 1 0 1 [0 0 0]]
>   with these character(s):
>     ⃣ (#x20e3) COMBINING ENCLOSING KEYCAP
>     ️ (#xfe0f) VARIATION SELECTOR-16

Thanks.  But does it really make sense to require that the default font
(on my system, Source Code Pro) support Emoji?  20E3 COMBINING ENCLOSING
KEYCAP displays by itself using Noto Color Emoji.

Previous Next

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