Yatao Li

auto detect = not using these values in the code.

Sorry I cannot do a screenshot at the moment (meh Wayland), but it looks just right for 18i8 :)

I have compiled a list of all emoji codepoints as of 12.0, here: https://github.com/yatli/fvim/blob/master/emoji.tsv It seems that the neovim is sticking to an older standard (perhaps 9.0? according to some...

yes `emoji` is set (though turning it off does not cause neovim to behave differently)

@dkasak yes, can confirm that. These glyphs are regarded as "narrow" by neovim.

@bfredl is there a case that ❤️(0x2764) alone without 0xFE0F makes it non-double-width? If not, I think it's better to just pick it from the lookup table, and not use...

I just looked up the unicode standard -- it is conflicting somehow. 0x2764 is listed as a valid codepoint, here: http://www.unicode.org/emoji/charts-12.0/emoji-list.html#2764 0x2764 has a mandatory VS, here: https://www.unicode.org/Public/emoji/12.0/emoji-sequences.txt 😕

~~Understood. :) In this case we’d need a slightly more complex mechanism.~~ edit: see comment below

TR51 states that, a base codepoint without a presentation selector will fall back to its default presentation:  0x2764 indeed has text presentation as its default fallback (from [wikipedia](https://en.wikipedia.org/wiki/Emoji)): ...

I think it means that there is no standard specifying that the default presentation is narrow (or wide, of course).