Repository navigation
Extra space cell inserted after unicode character #6162
Description
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.
Reacted by Ankit Bhatia, lursyy and Mr. Doge
Reacted by Gökçe
Metadata
Metadata
Assignees
Labels
Related to output processing (inserting text into buffer, retrieving buffer text, etc.)We encourage anyone to jump in on these.It either shouldn't be doing this or needs an investigation.A description (P2)For issues in the Console codebaseFor console issues specifically related to conptyFix is checked in, but it might be 3-4 weeks until a release.
Activity
DHowett commentedon May 23, 2020
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.
DHowett commentedon May 23, 2020
(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 commentedon May 24, 2020
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
WriteCharsLegacyfunction sees as two characters, thus moving forward two columns.lursyy commentedon Dec 21, 2020
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:
➜.➜.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?
2 remaining items
thchr commentedon Jan 5, 2022
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.suasgn commentedon Nov 16, 2022
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