Strange handling of multi-byte emoji / variation selector U+FE0E in ZLE

Strange handling of multi-byte emoji / variation selector U+FE0E in ZLE

[Elliott Cable]

Hi!

When entering emoji or Unicode glyphs on macOS, the selected glyph is
often inserted with a [Unicode 6.0 ‘variation selector’][1]. This
appears as two Unicode codepoints:

    echo '☺'   // echo -e '\u263A'
    echo '☺️'   // echo -e '\u263A\uFE0F'
    echo '☺︎'   // echo -e '\u263A\uFE0E'

(Those may appear differently in your e-mail client, of course — and
 that's assuming *my* Gmail web-interface doesn't mangle them in the
 sending ... so be careful as to how you interpret them: the first is
 undeclared, the second should be a colourful emoji, and the last should
 be an old-school, monochrome Unicode smiley glyph.)

Unfortunately, when these are entered at the command-line, ZLE's
character-count seems to get all wonky: rendering of the text entered so
far gets offset by one, backspacing behaves strangely, so-on and so-
forth.

I've reproduced this on two machines (though both macOS), in two
terminals (Terminal.app and Hyper.app), and on a couple recent zsh
versions.

Let me know if I should report this elsewhere, or if more debugging
information would be useful.

<U+1F61A> 😚!

   [1]: http://mts.io/2015/04/21/unicode-symbol-render-text-emoji/

Re: Strange handling of multi-byte emoji / variation selector U+FE0E in ZLE

[Jun T.]

(re-posting to users list)

> 2017/07/11 04:05、Elliott Cable <me@ell.io> wrote, 

>    echo '☺'   // echo -e '\u263A'
>    echo '☺️'   // echo -e '\u263A\uFE0F'
>    echo '☺︎'   // echo -e '\u263A\uFE0E'

> Unfortunately, when these are entered at the command-line, ZLE's
> character-count seems to get all wonky:

Could you please try the latest git master? About two months ago
We've added new Unicode-related functions to zsh, which correctly
recognize U+FF00 - U+FF0F as combining characters.
(The new functions are enabled by default on macOS)