In 6.2.3 and above PSReadLine causes 'backspace' in posh-git + Windows Terminal

[tig]

Environment data

• posh-git version/path: 1.0.0 beta3 ~\Documents\PowerShell\Modules\posh-git\1.0.0
• PowerShell version: 6.2.3
• git version 2.23.0.windows.1
• OS: Microsoft Windows NT 10.0.18362.0

Steps to reproduce or exception report

Please see this posh-git Issue for more details: dahlbyk/posh-git#704

@rkeithhill

[daxian-dbw]

Quoted from dahlbyk/posh-git#704 (comment)

I also noticed this, and posted about it in the Windows Terminal repository. Someone suggested it was caused by the ≡ character; at least where Cascadia Code is concerned, this is currently an "ambiguous-width" character, so the terminal's understanding of the cursor position becomes inconsistent. I think the older console that you get by launching pwsh.exe just forces everything to one character cell.

[msftrncs]

Then that makes this related to #1054. Character width is determined by the font … I don't know if PSReadLine has anyway it can determine this when its behind a terminal. Can the current character position be polled through a VT sequence? Spit out a character, poll the new cursor position, etc...?

[daxian-dbw]

Might be different. The linked issue description mentioned that it happens on Windows Terminal only:

EDIT: This does NOT happen in Hosts other than Windows Terminal. E.g. in the VSCode terminal, cmd.exe, and ConEmu it works fine.

[tig]

Might be different. The linked issue description mentioned that it happens on Windows Terminal only:

EDIT: This does NOT happen in Hosts other than Windows Terminal. E.g. in the VSCode terminal, cmd.exe, and ConEmu it works fine.

Correct. I was unable to reproduce in any host other than Windows Terminal.

Additionally, while the character width issue may be the culprit, my instincts say this is in PSReadline as @rkeithhill and I tested a PS 6.2.3 session in Windows Terminal WITHOUT PSReadLine loaded...and the font appeared correctly without the backspace issue.

[msftrncs]

If the issue is in fact that sometimes (some fonts) the ≡ is a different width, then this will affect PSReadLine's ability to estimate where the cursor is. PSReadLine attempts to modify the prompt as you type, so it has to move and move again the cursor while you are typing.

[msftrncs]

Difference in hosts could simply be the default font, or not demonstrating the issue using the same path and same Posh Git connections.

Also, as you type, PSReadLine may modify the color of previous parts of the command line, more reason that the cursor has to be moved, and why PSReadLine needs an accurate estimate of the cursor position.

[lzybkr]

See microsoft/terminal#2928 where they are assuming ambiguous width characters are 1 character.

Note that PSReadLine hard codes the characters that are double width here.

[vexx32]

Should emoji be / are they part of that list @lzybkr ?

[lzybkr]

Note in my link above the commented out code for surrogate pairs. Emoji have the same issue I think.

[DHowett-MSFT]

Specifically microsoft/terminal#2928 will enforce all ambiguous width chars being one cell wide -- this will fix this bug.

[tig]

Specifically microsoft/terminal#2928 will enforce all ambiguous width chars being one cell wide -- this will fix this bug.

Woot. Thanks.

[daxian-dbw]

microsoft/terminal#2928 was merged, so closing this issue.