Re: describe-char on emoji sequences

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> It's just a sequence of Unicode code points, surely?  (And the help
>> buffer lists them, but not in the format needed to enter them.)
>
> How can Emacs know that there is a special command that can be used to
> insert this entire sequence of codepoints in one go?

There isn't (well, there is now with emoji-insert), but...

Take ⚠️:

             to input: type "C-x 8 RET 26a0" or "C-x 8 RET WARNING SIGN"
          buffer code: #xE2 #x9A #xA0
            file code: #xE2 #x9A #xA0 (encoded by coding system utf-8-emacs)
              display: composed to form "⚠️" (see below)

Composed with the following character(s) "️" using this font:
  ftcrhb:-GOOG-Noto Color Emoji-medium-normal-normal-*-19-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 1 9888 112 24 0 24 18 5 nil]
with these character(s):
  ️ (#xfe0f) VARIATION SELECTOR-16

If you insert

C-x 8 RET WARNING SIGN and then C-x 8 RET VARIATION SELECTOR-16 you
indeed get:

⚠️

So 

             to input: type "C-x 8 RET 26a0" or "C-x 8 RET WARNING SIGN"

could just be expanded to include all the code points in the
decomposition.  Of course, with some of these sequences (with five code
points), doing this is completely impractical, so perhaps it's not worth
doing. 

> Because it doesn't necessarily have a name.  This is a general-purpose
> command, it is capable of describing any result of any character
> composition, including those which yield more than one glyph and
> glyphs that have no name.  (Technically, the correct terminology is
> "grapheme cluster", not "glyph".)

I had a feeling that "glyph" wasn't correct.  :-)

> We could, of course, program describe-char to give special treatment
> to glyphs produced from the Emoji sequences, but that has to be coded
> explicitly and specially for Emoji, because I don't see how you can do
> that for an arbitrary composition.

Yes, that's what I was thinking -- if we had a table that goes from
grapheme cluster to name (and those would only be filled in for emojis),
then we could output that name.  (emoji.el creates such a table, but I
don't think we'd want to load that from this command, so the table
should perhaps be created in a more central location.)

The point of this is that it's not always clear what an emoji is trying
to express.  For instance, if somebody writes you a message about 👨🏻‍✈️,
it'd be nice if Emacs could tell you that it's a "man pilot".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no