Rendering issue/glitches with files containing emojis on Windows

[fnuttens]

Summary

Hi!

I noticed some glitches when manipulating buffers containing emojis on Windows (Windows Terminal - also visible my WSL distro, and Cmd):

• in some cases, emojis take up 2x less space, which has the effect of shifting all other characters on the line
• sometimes the emojis are replaced by "square" characters
• some parts of the line are replaced by a black background

Here are two screenshots that should speak for themselves:

If needed, I will gladly make a recording of this, as the glitches are really correlated to the cursor's movements.

Reproduction Steps

The problem is replicable with any buffer containing at least one emoji. You just have to move the cursor on the same line to see all the following characters shift as the emoji itself changes in size.

Helix log

No log produced.

Platform

Windows

Terminal Emulator

Windows Terminal, Cmd

Helix Version

helix 22.08.1 (66276ce)

[CptPotato]

I can kind of reproduce this, though it looks a bit different on wezterm. I'll see if I can reproduce on linux as well but at at least on windows it happens regardless of line endings.

For reference, I used this text:

🖋️🖋️
🖋️🖋️

Moving around the cursor results in duplicates and seemingly broken diffing. You can see the light blue cell of the cursor appears multiple times in the screenshot, even though there's just one single width cursor. Emojis after the cursor are shifted left and extend into the gutter.

^{(don't mind the hidden line numbers)}

It seems like helix (or something) expects the emoji to be two cells wide, while the terminal displays it as 1 cell. This isn't the case for all emojis though. 🦀 is correctly displayed at 2 cells wide and works fine.

Neovim looks similarly broken, i.e. characters appearing where they shouldn't be on lines with the 🖋️ emoji, while 🦀 appears fine. It doesn't have the diffing issues but that might be down to more aggressive redrawing of cells.

[kirawi]

unicode-rs/unicode-width#4 (comment)

[pascalkuthe]

Closing in favor of #6012