bug#54562: 28.0.91; Emoji sequence not composed

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 54562@debbugs.gnu.org
> Date: Fri, 25 Mar 2022 18:32:08 +0800
> 
> Eli Zaretskii <eliz@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.

U+20E3 is not an Emoji character, so how do you want Emacs to know to
use the Emoji font for it?  And "7" is definitely not Emoji.