Cursor moving by more than one character #13520

@237dmitry commented on GitHub (Apr 18, 2021):

I have met many times when people did not know why in bash in different terminals they have problems with text output, with the cursor, etc. The very first problem is the wrong $PS1. It is necessary to escape the esc-sequences in it. Check your ~/.bashrc.

@237dmitry commented on GitHub (Apr 18, 2021): I have met many times when people did not know why in bash in different terminals they have problems with text output, with the cursor, etc. The very first problem is the wrong $PS1. It is necessary to escape the esc-sequences in it. Check your `~/.bashrc`.

claunia commented

@thuris commented on GitHub (Apr 18, 2021):

My .bashrc files are quite generic. I haven't done anything special with my prompt nor with shell inputs. And the cursor behavior appears on the openSUSE distro that I just installed from the MSFT Store, where I have done nothing besides log in and browse
a few directories.

It's not that the shell is reacting to string inputs in a peculiar way (it isn't) but that Terminal seems to compute the horizontal displacement of the cursor using a different value from the width of those characters as rendered by Terminal...but only for one font, and only in WSL, and only when that WSL distro is opened in its own tab -- doesn't happen if I am using PowerShell in a Terminal tab with that font and run the wsl command there.

@thuris commented on GitHub (Apr 18, 2021): My .bashrc files are quite generic. I haven't done anything special with my prompt nor with shell inputs. And the cursor behavior appears on the openSUSE distro that I just installed from the MSFT Store, where I have done nothing besides log in and browse a few directories. It's not that the shell is reacting to string inputs in a peculiar way (it isn't) but that Terminal seems to compute the horizontal displacement of the cursor using a different value from the width of those characters as rendered by Terminal...but only for one font, and only in WSL, and only when that WSL distro is opened in its own tab -- doesn't happen if I am using PowerShell in a Terminal tab with that font and run the wsl command there.

claunia commented

@zadjii-msft commented on GitHub (Apr 19, 2021):

What the heck?

Having the cursor drift like that kinda makes sense if the font isn't exactly monospaced. I've never heard of "Office Code Pro D" before, but it's possible there's something slightly weird about the way that it's authored that confuses the Terminal. I'm not sure why it would have regressed this most recent release, but I can at least imagine how that's possible.

What bewilders me is that this only repros in bash, not cmd or powershell. That's absolutely wild.

I don't have the faintest clue what we would have changed about font loading in 1.7 that could have caused this. This is where I tag in @miniksa

@zadjii-msft commented on GitHub (Apr 19, 2021): What the heck? Having the cursor drift like that kinda makes sense if the font isn't exactly monospaced. I've never heard of "Office Code Pro D" before, but it's possible there's something slightly weird about the way that it's authored that confuses the Terminal. I'm not sure why it would have regressed this most recent release, but I can at least imagine how that's possible. What bewilders me is that this only repros in `bash`, not `cmd` or `powershell`. That's absolutely wild. I don't have the faintest clue what we would have changed about font loading in 1.7 that could have caused this. This is where I tag in @miniksa

claunia commented

@DHowett commented on GitHub (Apr 19, 2021):

I wish we could have seen a screenshot of your terminal from before 1.7 😄

If you download the 1.6 msixbundle (stable, not preview!) from the releases page, you can install it without losing your settings from Windows PowerShell:

Add-AppxPackage Microsoft.WindowsTerminal_1.6.10571.0_8wekyb3d8bbwe.msixbundle -ForceUpdateFromAnyVersion

(The key is, of course, -ForceUpdateFromAnyVersion)

I'm wondering if Terminal 1.6 selected a different font and 1.7's new fallback algorithm (which shouldn't be hit since you are not seeing fallback) is choosing another variant?

@DHowett commented on GitHub (Apr 19, 2021): I wish we could have seen a screenshot of your terminal from before 1.7 :smile: If you download the [1.6 msixbundle](https://github.com/microsoft/terminal/releases/download/v1.6.10571.0/Microsoft.WindowsTerminal_1.6.10571.0_8wekyb3d8bbwe.msixbundle) (stable, not preview!) from the releases page, you can install it without losing your settings from Windows PowerShell: ```powershell Add-AppxPackage Microsoft.WindowsTerminal_1.6.10571.0_8wekyb3d8bbwe.msixbundle -ForceUpdateFromAnyVersion ``` (The key is, of course, `-ForceUpdateFromAnyVersion`) I'm wondering if Terminal 1.6 selected a different font and 1.7's new fallback algorithm (**which shouldn't be hit since you are not seeing fallback**) is choosing another variant?

claunia commented

https://github.com/nathco/Office-Code-Pro

@miniksa commented on GitHub (Apr 19, 2021):

To be clear, this is the font we're talking about, right?

@miniksa commented on GitHub (Apr 19, 2021): To be clear, this is the font we're talking about, right? https://github.com/nathco/Office-Code-Pro

claunia commented

@thuris commented on GitHub (Apr 19, 2021):

(The comment below is about behavior in 1.7)
I'm seeing no clear pattern to when this happens. For a minute I thought it was only occurring when I changed the font size in the settings UI after opening the tab in question. But sometimes changes in the settings UI do not cause it, and sometimes I open a tab and the behavior is there from distro startup.

The most peculiar thing I've seen is this sequence...with one character entered the cursor is too far away:

Then with two characters, cursor is still too far:

But with three or more characters entered, although the cursor appears to move by the same amount as before, the entire line (prompt and all) is immediately re-rendered with a spacing that brings the final character flush with the cursor:

Maybe equally surprising is that if I then backspace so that only two characters follow the prompt, the entire line reverts to the "two characters plus extra space" appearance of the second. And as often as I go up to three or back down to two, this behavior repeats.

[EDIT: I thought maybe this had to do with the number of characters on the line, so I went to a different directory to see if I would need to enter more characters or fewer to get the same result.

But it turns out I can enter any number of characters...

Provided there is no L/l:

It treats L, whether upper or lowercase, differently from every other character. As soon as there is an L/l, no matter the context, the entire line is re-spaced in such a way that the end of the text meets the cursor.

Also I saw something peculiar with URLs, thus:

And:

Each time I type a period, the period abuts the cursor but leaves empty space to the left. Then when I enter more of the URL, the end of the text shifts leftward after about half a second:

This is different from the behavior I opened this issue about, which was the cursor always drifting further from the right edge of the text.

One other behavior I noticed that might conceivably relate to any or all of this: After closing all distros and doing wsl --shutdown, I went into the settings UI and changed the font weight for openSUSE from Normal to Medium. I then started up a tab with that distro. When the prompt came up, for maybe a third of a second it was at the Normal weight (the previous setting) and then shifted to Medium.

If this is just some oddity of my machine and configuration, I'm fine to go back to using other fonts within Terminal and stop complaining about it! Ultimately, it's not a huge problem...but it is puzzling, since the font in question works for me with no issues in VS 2019, VS Code and Sublime Text.

@thuris commented on GitHub (Apr 19, 2021): (The comment below is about behavior in 1.7) I'm seeing no clear pattern to when this happens. For a minute I thought it was only occurring when I changed the font size in the settings UI *after* opening the tab in question. But sometimes changes in the settings UI do not cause it, and sometimes I open a tab and the behavior is there from distro startup. The most peculiar thing I've seen is this sequence...with one character entered the cursor is too far away: ![image](https://user-images.githubusercontent.com/2650103/115275719-053a3880-a0f7-11eb-9349-49ba1ecb3f9f.png) Then with two characters, cursor is still too far: ![image](https://user-images.githubusercontent.com/2650103/115275863-3286e680-a0f7-11eb-9663-ddc2aab2b7da.png) But with three or more characters entered, although the cursor appears to move by the same amount as before, the entire line (prompt and all) is immediately re-rendered with a spacing that brings the final character flush with the cursor: ![image](https://user-images.githubusercontent.com/2650103/115276232-a32e0300-a0f7-11eb-8417-04e23940fded.png) Maybe equally surprising is that if I then backspace so that only two characters follow the prompt, the entire line reverts to the "two characters plus extra space" appearance of the second. And as often as I go up to three or back down to two, this behavior repeats. [**EDIT:** I thought maybe this had to do with the number of characters on the line, so I went to a different directory to see if I would need to enter more characters or fewer to get the same result. But it turns out I can enter any number of characters... ![image](https://user-images.githubusercontent.com/2650103/115280317-a5df2700-a0fc-11eb-9ebb-ff64ef04dbab.png) Provided there is no L/l: ![image](https://user-images.githubusercontent.com/2650103/115280464-d0c97b00-a0fc-11eb-981e-36e2379ec6a1.png) It treats L, whether upper or lowercase, differently from every other character. As soon as there is an L/l, no matter the context, the entire line is re-spaced in such a way that the end of the text meets the cursor. Also I saw something peculiar with URLs, thus: ![image](https://user-images.githubusercontent.com/2650103/115281028-6b29be80-a0fd-11eb-8493-be2f3eddf12e.png) And: ![image](https://user-images.githubusercontent.com/2650103/115281241-a1ffd480-a0fd-11eb-9a21-ded3e4ce9aa3.png) Each time I type a period, the period abuts the cursor but leaves empty space to the left. Then when I enter more of the URL, the end of the text shifts leftward after about half a second: ![image](https://user-images.githubusercontent.com/2650103/115281456-e2f7e900-a0fd-11eb-9b41-943d43420ccc.png) This is different from the behavior I opened this issue about, which was the cursor always drifting further from the right edge of the text. One other behavior I noticed that might conceivably relate to any or all of this: After closing all distros and doing wsl --shutdown, I went into the settings UI and changed the font weight for openSUSE from Normal to Medium. I then started up a tab with that distro. When the prompt came up, for maybe a third of a second it was at the Normal weight (the previous setting) and then shifted to Medium. If this is just some oddity of my machine and configuration, I'm fine to go back to using other fonts within Terminal and stop complaining about it! Ultimately, it's not a huge problem...but it is puzzling, since the font in question works for me with no issues in VS 2019, VS Code and Sublime Text.

claunia commented

@thuris commented on GitHub (Apr 19, 2021):

@miniksa

To be clear, this is the font we're talking about, right?

https://github.com/nathco/Office-Code-Pro

Yes, that's the one! The only difference between the normal and "D" version of the font is that the zero is dotted rather than slashed.

@thuris commented on GitHub (Apr 19, 2021): @miniksa > To be clear, this is the font we're talking about, right? > > https://github.com/nathco/Office-Code-Pro Yes, that's the one! The only difference between the normal and "D" version of the font is that the zero is dotted rather than slashed.

claunia commented

@thuris commented on GitHub (Apr 19, 2021):

@DHowett I reinstalled 1.6, overwriting my 1.7 install (possibly because I didn't run Powershell as admin) but preserving my settings. And with 1.6 I'm getting the same behaviors described in my posts about 1.7, leading me to think this might be related to the Windows update from roughly two weeks ago (the one immediately before 19043.928 on the beta channel).

[EDIT: I reinstalled 1.7 over 1.6 again with no problem, settings intact.]

@thuris commented on GitHub (Apr 19, 2021): @DHowett I reinstalled 1.6, overwriting my 1.7 install (possibly because I didn't run Powershell as admin) but preserving my settings. And with 1.6 I'm getting the same behaviors described in my posts about 1.7, leading me to think this might be related to the Windows update from roughly two weeks ago (the one immediately before 19043.928 on the beta channel). [EDIT: I reinstalled 1.7 over 1.6 again with no problem, settings intact.]

claunia commented

@thuris commented on GitHub (Apr 19, 2021):

@zadjii-msft

What bewilders me is that this only repros in bash, not cmd or powershell. That's absolutely wild.

It was bothering me too, so I tried it again and did get the weird behavior on Powershell 7. I don't normally use that font with pwsh, and the behavior didn't show when I tested it briefly. But the behavior appears somewhat random, so I tried it again today and got the cursor weirdness there. I've just now gone back to edit my first post to reflect that.

@thuris commented on GitHub (Apr 19, 2021): @zadjii-msft > > What bewilders me is that this only repros in `bash`, not `cmd` or `powershell`. That's absolutely wild. > It was bothering me too, so I tried it again and *did* get the weird behavior on Powershell 7. I don't normally use that font with pwsh, and the behavior didn't show when I tested it briefly. But the behavior appears somewhat random, so I tried it again today and got the cursor weirdness there. I've just now gone back to edit my first post to reflect that.

claunia commented

@rtm commented on GitHub (Jul 15, 2021):

I'm getting the same behavior using Cascadia Code in a browser-based terminal on Linux.

However, for reasons I cannot discern, possibly related to the window losing and then regaining focus, it sometimes fixes itself and return to normal behavior.

@rtm commented on GitHub (Jul 15, 2021): I'm getting the same behavior using Cascadia Code in a browser-based terminal on Linux. However, for reasons I cannot discern, possibly related to the window losing and then regaining focus, it sometimes fixes itself and return to normal behavior.

claunia commented

@HymanZHAN commented on GitHub (Apr 10, 2022):

Not sure if it's 100% the same issue, but I guess it's related. I use the CodeNewRoman Nerd Font typeface on both the Windows Terminal and VS Code terminal. The rendering difference is something like this:

VS Code terminal (WSL2), no cursor shifting
Windows Terminal (WSL2), cursor shifting

Got inspired by previous comments and switched the typeface of Windows Terminal to CodeNewRoman Nerd Font Mono, and it did the trick.

Windows Terminal (WSL2) + the Mono variant font, no cursor shifting

I never thought the CodeNewRoman Nerd Font typeface was "non-mono" because I have been using it across different shells on different OS, and Windows Terminal has been the only place where it shows this weird "shifting" behavior. I can help with testing if that's helpful.

@HymanZHAN commented on GitHub (Apr 10, 2022): Not sure if it's 100% the same issue, but I guess it's related. I use the `CodeNewRoman Nerd Font` typeface on both the Windows Terminal and VS Code terminal. The rendering difference is something like this: - VS Code terminal (WSL2), no cursor shifting ![Screenshot 2022-04-10 143744](https://user-images.githubusercontent.com/26806995/162606150-ea9e3673-0900-456d-9f57-7d35986afecd.png) - Windows Terminal (WSL2), cursor shifting ![Screenshot 2022-04-10 143855](https://user-images.githubusercontent.com/26806995/162606154-ff4abca3-b402-479e-8ee7-b2e0079985d3.png) Got inspired by previous comments and switched the typeface of Windows Terminal to `CodeNewRoman Nerd Font Mono`, and it did the trick. - Windows Terminal (WSL2) + the `Mono` variant font, no cursor shifting ![Screenshot 2022-04-10 144543](https://user-images.githubusercontent.com/26806995/162606160-ac2a65ca-0d31-44d4-a768-d0ce6057d0f7.png) I never thought the `CodeNewRoman Nerd Font` typeface was "non-mono" because I have been using it across different shells on different OS, and Windows Terminal has been the only place where it shows this weird "shifting" behavior. I can help with testing if that's helpful.

claunia commented

@zadjii-msft commented on GitHub (Aug 23, 2023):

I wonder if the new text renderer in 1.18 fixes this... It might just do a better job of laying out not-quite-exactly-monospaced fonts.

Anyone who was seeing this before wanna give Terminal Preview and let us know if this was fixed/?

@zadjii-msft commented on GitHub (Aug 23, 2023): I wonder if the new text renderer in 1.18 fixes this... It might just do a better job of laying out not-quite-exactly-monospaced fonts. Anyone who was seeing this before wanna give [Terminal Preview](https:://aka.ms/terminal-preview) and let us know if this was fixed/?

claunia commented