bug#54562: 28.0.91; Emoji sequence not composed

[Po Lu]

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.