Extra space cell inserted after unicode character

[willmcgugan]

Environment

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.18363.0 Microsoft Windows NT 10.0.18363.0

Terminal v1.0.1401.0

Steps to reproduce

Write the following string to the terminal (Python):

>>> print("│\x1b[33m\U0001F862\x1b[0m│")

This string is a unicode box char, followed by a foreground yellow escape, a unicode arrow, a reset escape, and another box character.

Expected behavior

The string should render three characters: a vertical line, yellow arrow, vertical line.

Actual behavior

There is an extra space after the arrow.

Note that this only occurs with that particular unicode character. If I replace that unicode arrow with any other character then it renders as expected.

[DHowett]

This is wild. Through-and-through, the infrastructure believes this to be a single-cell glyph. We're doing the right thing by the UCD, but then when the pseudoconsole emits it it emits it with an additional cursor move.

␛[?25h|␛[33m🡢␛[m␛[1C|␍␊
                 ^^^^
                 here

[DHowett]

(And of course, only when there's a color run break. This sound ominously related to our attribute run splitter and how it thinks the cursor moves when it splits runs.)

[j4james]

I think this is actually a conhost problem - you'll see the same issue there. The conpty sequence is just trying to reproduce the state of the conhost buffer which is already incorrect.

And the color change isn't really what's triggering it - any control character will do. The state machine splits up runs of text separated by control characters. And once a run of text is written, the cursor position is moved forward the expected number of columns (which in this case is off by 1). The next run of text is then starting in the wrong position, so you get a gap.

And the reason why it's off by 1 is because the character is processed as a surrogate pair, which the WriteCharsLegacy function sees as two characters, thus moving forward two columns.

[lursyy]

I have another arrow example which I believe is related:

The robbyrussell prompt for zsh and fish uses the "➜" (U+279C) character.
It renders nicely (i.e. two characters wide) in the VS Code integrated terminal (irrespective of the font setting). Here I selected the first character for illustration:

In MS Terminal however, it renders as a single arrow followed by space (again, with first char selected):

FWIW:

• When copying the single-character arrow from MS Terminal, I get ➜.
• When copying the first part of the double-character arrow (i.e. the "stem") from VS Code, I get ➜.
• When copying the second part of the double-character arrow (i.e. the "tip") from VS Code, I get . (Seems to be a plain old space?)

Do VS Code and MS Terminal share some of the underlying infrastructure in that regard? If so, one could take a look at how it works over there?

[thchr]

There's a similar issue with the 𝑝 character (unicode U+1D45D): sometimes, a space will be inserted after 𝑝, sometimes it won't.
Similarly, even typing 𝑝 in WSL displayed on Terminal will basically garble that whole line.

[suabahasa]

I face a similar issue as described on oh-my-posh/issues#3088

The font I use is Caskaydia Cove Nerd Font

Oh My Posh v12.14.0

Windows Terminal - Version: 1.15.2875.0

[ghost]

🎉This issue was addressed in #14640, which has now been successfully released as Windows Terminal Preview v1.17.1023.:tada:

Handy links:

• Release Notes
• Store Download