Unicode emoji with VARIATION SELECTOR-16 sometimes mis-renders

[cgull]

I don't know yet if this is distinct from the more basic Unicode issues Mosh has, but:
This: '☺️' sometimes renders correctly as a double-wide emoji graphic, but sometimes renders incorrectly as a single wide emoji glyph. This of course is not good; the display is corrupted.

Mozilla and/or the Github editor may have mangled that, but the contents are U+263A, U+FE0F.
The first is the standard smiley emoji, the second is VARIATION SELECT-15, which in the context of an emoji means emoji style (as opposed to VARIATION SELECT-15, which is text style).

The person who generated that on IRC says it came from Colloquy on a Mac, with OS X's input text replacement converting ':)' to that.

[cgull]

Oops, typo in my original post. From Wikipedia:

"Emoji variation sequences contain VS16 (U+FE0F) for emoji-style or VS15 (U+FE0E) for text style"

And this looks like a special variety of ugly. If the text/emoji variants are indeed supposed to change the display width too, then Mosh will need code to observe the VARIATION SELECT codepoint going by and change the width of the cell they're associated with-- but only for emoji, or something.

[cgull]

It's even slightly worse than that: emoji-style overrides the base character's width to be East Asian Wide. http://www.unicode.org/reports/tr11/tr11-31.html#Recommendations, last line of that section. @andersk has also found that Unicode 9.0 changed all emojis to be treated as East Asian Wide.

[achernya]

This is a duplicate of #234