starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

The cursor jumps to the end of the line and immediately returns to the correct position when typing in a Git Bash profile #8616

New Issue
Open
opened 2026-01-31 01:33:54 +00:00 by claunia · 15 comments
claunia commented 2026-01-31 01:33:54 +00:00
Owner
Copy Link

Originally created by @slangreck on GitHub (May 27, 2020).

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.836]
Windows Terminal version (if applicable): 1.0.1401.0

Any other software?
- Git for Windows

Steps to reproduce

Open a Git Bash tab. My profile looks like this:

{
	"guid": "{7f9476f7-58ca-491b-b101-43b38738ebcb}",
	"name" : "Git Bash",
	"tabTitle": "Git Bash",
	"commandline" : "\"%ProgramFiles%\\Git\\usr\\bin\\bash.exe\" -i -l",
	"hidden": false,
	"startingDirectory" : "C:\\Git",
	"closeOnExit" : true,
	"colorScheme" : "Solarized Dark",
	"cursorColor" : "#FFFFFF",
	"cursorShape" : "bar",
	"fontSize" : 10,
	"historySize" : 9001,
	"icon" : "%ProgramFiles%\\Git\\mingw64\\share\\git\\git-for-windows.ico",
	"padding" : "8, 8, 8, 8",
	"snapOnInput" : true,
	"useAcrylic" : false
}

Type something like git commit -m "" and press left arrow to put your cursor into the quote marks.
Then type a commit message.

Expected behavior

After you type a character the cursor should be drawn directly after that character.

Actual behavior

The cursor jumps to the end of the line before returning to the correct position. Here is a gif of it happening:
JumpingCursor
The jumping happens with every typed character, but because of framerate reasons the gif only captured a jump after the second r in "cursor" and the m in "jumps".

Originally created by @slangreck on GitHub (May 27, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: Microsoft Windows [Version 10.0.18362.836] Windows Terminal version (if applicable): 1.0.1401.0 Any other software? - Git for Windows ``` # Steps to reproduce Open a Git Bash tab. My profile looks like this: ```JSON { "guid": "{7f9476f7-58ca-491b-b101-43b38738ebcb}", "name" : "Git Bash", "tabTitle": "Git Bash", "commandline" : "\"%ProgramFiles%\\Git\\usr\\bin\\bash.exe\" -i -l", "hidden": false, "startingDirectory" : "C:\\Git", "closeOnExit" : true, "colorScheme" : "Solarized Dark", "cursorColor" : "#FFFFFF", "cursorShape" : "bar", "fontSize" : 10, "historySize" : 9001, "icon" : "%ProgramFiles%\\Git\\mingw64\\share\\git\\git-for-windows.ico", "padding" : "8, 8, 8, 8", "snapOnInput" : true, "useAcrylic" : false } ``` Type something like `git commit -m ""` and press left arrow to put your cursor into the quote marks. Then type a commit message. # Expected behavior After you type a character the cursor should be drawn directly after that character. # Actual behavior The cursor jumps to the end of the line before returning to the correct position. Here is a gif of it happening: ![JumpingCursor](https://user-images.githubusercontent.com/31589520/82997153-4c629b00-a006-11ea-9fe9-32fe3b67d345.gif) The jumping happens with every typed character, but because of framerate reasons the gif only captured a jump after the second `r` in "cursor" and the `m` in "jumps".
claunia commented 2026-01-31 01:33:55 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 2, 2020):

When I run bash under "script" (which captures its output), it looks like this is exactly what the shell is emitting.

git commit -m ""
               | cursor before "

If I type x, I get this:

x"<BS>

which advances the cursor two cells and then puts the cursor back before the ".

Make no mistake -- this is how all terminal emulators are handling it. It just so happens that our cursor updates are visible through the " and <BS>. I'm not convinced that that's wrong.

If somebody wants to look at this, they may consider moving the cursor.StartDefer... up to Terminal::Write instead of Terminal::_WriteBuffer. The former is pre-vt, the latter is post-vt. Deferring once per packet instead of once per run of plain text may improve the appearance.

@DHowett commented on GitHub (Jun 2, 2020): When I run bash under "script" (which captures its output), it looks like this is exactly what the shell is emitting. ``` git commit -m "" | cursor before " ``` If I type `x`, I get this: ``` x"<BS> ``` which advances the cursor two cells and then puts the cursor back before the `"`. Make no mistake -- this is how all terminal emulators are handling it. It just so happens that our cursor updates are visible through the `"` and `<BS>`. I'm not convinced that that's _wrong_. If somebody wants to look at this, they may consider moving the `cursor.StartDefer...` up to Terminal::Write instead of Terminal::_WriteBuffer. The former is pre-vt, the latter is post-vt. Deferring once per packet instead of once per _run of plain text_ may improve the appearance.
claunia commented 2026-01-31 01:33:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 8, 2020):

Note: I tried fixing this in conjunction with #1087 this morning. Just moving the StartDefer... call up a layer didn't work, because we'd never invalidate the cell the cursor was on at the start of the deferring, which would leave cursor turds all over the screen. That particular method is currently only used during a resize operation, so while it works for the purpose of suppressing the number of Renderer::TriggerFrame calls we make, that's not really useful for hiding the cursor till the output is done being processed.

@zadjii-msft commented on GitHub (Jun 8, 2020): Note: I tried fixing this in conjunction with #1087 this morning. Just moving the `StartDefer...` call up a layer didn't work, because we'd never invalidate the cell the cursor was on at the start of the deferring, which would leave cursor turds all over the screen. That particular method is currently only used during a resize operation, so while it works for the purpose of suppressing the number of `Renderer::TriggerFrame` calls we make, that's not really useful for hiding the cursor till the output is done being processed.
claunia commented 2026-01-31 01:33:56 +00:00
Author
Owner
Copy Link

@slangreck commented on GitHub (Oct 26, 2020):

This seems to be fixed in recent versions, at least I am not seeing it any more.

@slangreck commented on GitHub (Oct 26, 2020): This seems to be fixed in recent versions, at least I am not seeing it any more.
claunia commented 2026-01-31 01:33:56 +00:00
Author
Owner
Copy Link

@jdrouhard commented on GitHub (Aug 31, 2021):

Can we reopen this? I'm still seeing this on the most recent build of Windows Terminal Preview.

I'm wondering if this is the same root cause for another problem I have. If I'm doing nothing at my zsh prompt (or inside neovim), the cursor will flicker occasionally instead of staying solid. Is it because Terminal is processing cursor updates faster than zsh/neovim can redraw?

@jdrouhard commented on GitHub (Aug 31, 2021): Can we reopen this? I'm still seeing this on the most recent build of Windows Terminal Preview. I'm wondering if this is the same root cause for another problem I have. If I'm doing nothing at my zsh prompt (or inside neovim), the cursor will flicker occasionally instead of staying solid. Is it because Terminal is processing cursor updates faster than zsh/neovim can redraw?
claunia commented 2026-01-31 01:33:56 +00:00
Author
Owner
Copy Link

@slangreck commented on GitHub (Sep 1, 2021):

Sure, I'll reopen it. I haven't seen this happening any more since I closed the issue though, so it seems as if it depends on your local setup.

@slangreck commented on GitHub (Sep 1, 2021): Sure, I'll reopen it. I haven't seen this happening any more since I closed the issue though, so it seems as if it depends on your local setup.
claunia commented 2026-01-31 01:33:56 +00:00
Author
Owner
Copy Link

@arminveres commented on GitHub (Sep 2, 2021):

Good thing it was reopened yesterday. I just set up git bash on terminal and I'm getting this issue as well.

@arminveres commented on GitHub (Sep 2, 2021): Good thing it was reopened yesterday. I just set up git bash on terminal and I'm getting this issue as well.
claunia commented 2026-01-31 01:33:57 +00:00
Author
Owner
Copy Link

@Vyogami commented on GitHub (Oct 23, 2021):

I'm getting the same issue in my git bash when running it on windows terminal

@Vyogami commented on GitHub (Oct 23, 2021): I'm getting the same issue in my git bash when running it on windows terminal
claunia commented 2026-01-31 01:33:57 +00:00
Author
Owner
Copy Link

@Krispyru commented on GitHub (May 19, 2024):

I'm getting the issue only when i have zsh-syntax-highlighting plugin enabled in git bash. It might have to do with changing color of the text while typing?

This also only happens in the windows terminal. Inside intelliJ or vscode virtual console seems to not jump or flicker

@Krispyru commented on GitHub (May 19, 2024): I'm getting the issue only when i have zsh-syntax-highlighting plugin enabled in git bash. It might have to do with changing color of the text while typing? This also only happens in the windows terminal. Inside intelliJ or vscode virtual console seems to not jump or flicker
claunia commented 2026-01-31 01:33:57 +00:00
Author
Owner
Copy Link

@marovira commented on GitHub (Nov 24, 2024):

I wanted to provide some further information I just found when testing to narrow down which ZSH plugins cause the flickering issue.

Testing Setup

  • All of my tests were conducted using both the latest preview release of Terminal (1.22.3232.0) and the latest official release of Terminal (1.21.3231.0).
  • The reported issues can be reproduced on any terminal running ZSH. From my testing, it is reproducible in any of:
    • Git bash with ZSH,
    • WSL with ZSH,
    • SSH into a remote Linux host with ZSH.

To ensure a clean environment, I removed all plugins from my ZSH config, ensuring the environment was clean before testing each plug-in individually.

Results

The flickering issue can be reproduced when the zsh-users/zsh-syntax-highlighting plug-in is enabled. That being said, having a theme enabled (such as powerlevel10k) and having additional plug-ins such as zsh-users/zsh-autosuggestions exacerbates the issue. Removing the zsh-users/zsh-syntax-highlighting causes the flickering to disappear.

I will also note that the issue appears to have been fixed (or at least it is not noticeable) in Terminal version 1.18.10301.0. I have tested later versions and they all have the flickering issue present.

@marovira commented on GitHub (Nov 24, 2024): I wanted to provide some further information I just found when testing to narrow down which ZSH plugins cause the flickering issue. # Testing Setup * All of my tests were conducted using both the latest preview release of Terminal (1.22.3232.0) and the latest official release of Terminal (1.21.3231.0). * The reported issues can be reproduced on **any** terminal running ZSH. From my testing, it is reproducible in any of: * Git bash with ZSH, * WSL with ZSH, * SSH into a remote Linux host with ZSH. To ensure a clean environment, I removed all plugins from my ZSH config, ensuring the environment was clean before testing each plug-in individually. # Results The flickering issue can be reproduced when the `zsh-users/zsh-syntax-highlighting` plug-in is enabled. That being said, having a theme enabled (such as powerlevel10k) and having additional plug-ins such as `zsh-users/zsh-autosuggestions` exacerbates the issue. Removing the `zsh-users/zsh-syntax-highlighting` causes the flickering to disappear. I will also note that the issue appears to have been fixed (or at least it is not noticeable) in Terminal version 1.18.10301.0. I have tested later versions and they all have the flickering issue present.
claunia commented 2026-01-31 01:33:57 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Nov 26, 2024):

I suspect what caused this in newer versions is that we do not delay rendering anymore when we receive input. So, if an application sends "some" followed by "text", we may now render "some" and then "some text" in the next frame. The ideal solution is for applications to be mindful over when to emit text to stdout and make so to always emit "some text" in a single print. (I.e. don't printf multiple times for a single prompt in your zsh script.) I'm not sure if there's an ideal solution for the terminal side as it can't look into the future to know if there will be more text coming in.

What I think we could do is a technique called "late latching", commonly used in VR rendering and perhaps newer FPS to reduce input latency by delaying rendering until shortly before the next v-blank. But I believe even that only reduces the rate of flickering, and does not fix it.

@lhecker commented on GitHub (Nov 26, 2024): I suspect what caused this in newer versions is that we do not delay rendering anymore when we receive input. So, if an application sends "some" followed by "text", we may now render "some" and then "some text" in the next frame. The ideal solution is for applications to be mindful over when to emit text to `stdout` and make so to always emit "some text" in a single print. (I.e. don't `printf` multiple times for a single prompt in your zsh script.) I'm not sure if there's an ideal solution for the terminal side as it can't look into the future to know if there will be more text coming in. What I think we could do is a technique called "late latching", commonly used in VR rendering and perhaps newer FPS to reduce input latency by delaying rendering until shortly before the next v-blank. But I believe even that only reduces the rate of flickering, and does not fix it.
claunia commented 2026-01-31 01:33:57 +00:00
Author
Owner
Copy Link

@marovira commented on GitHub (Nov 27, 2024):

If it could be reduced so it's barely noticeable, I think that would be a huge improvement. That said, I do want to mention that out of all the terminal emulators I've tried (Guake, Yakuake, Konsole, Gnome terminal, and Kitty) only the Windows Terminal has issues with ZSH and syntax highlighting. Could help in finding a better solution down the line?

@marovira commented on GitHub (Nov 27, 2024): If it could be reduced so it's barely noticeable, I think that would be a huge improvement. That said, I do want to mention that out of all the terminal emulators I've tried (Guake, Yakuake, Konsole, Gnome terminal, and Kitty) only the Windows Terminal has issues with ZSH and syntax highlighting. Could help in finding a better solution down the line?
claunia commented 2026-01-31 01:33:58 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Dec 2, 2024):

In case of WSL and zsh-users/zsh-syntax-highlighting I found that I can fix the flickering if I set appendWindowsPath=false in my /etc/wsl.conf. Without having read the plugin's source code, this may indicate that zsh-users/zsh-syntax-highlighting draws the text once without colorization, then resolves whether the given executable name is valid, and then applies the colorization. That will of course lead to flickering if resolving the executable path takes too long.

@lhecker commented on GitHub (Dec 2, 2024): In case of WSL and `zsh-users/zsh-syntax-highlighting` I found that I can fix the flickering if I set `appendWindowsPath=false` in my `/etc/wsl.conf`. Without having read the plugin's source code, this may indicate that `zsh-users/zsh-syntax-highlighting` draws the text once without colorization, then resolves whether the given executable name is valid, and then applies the colorization. That will of course lead to flickering if resolving the executable path takes too long.
claunia commented 2026-01-31 01:33:58 +00:00
Author
Owner
Copy Link

@marovira commented on GitHub (Dec 2, 2024):

I don't think the resolution of executable paths is to blame here, at least not when running ZSH in Git bash and certainly not when it's running on a Linux server. As I mentioned in my previous reply, the flickering issue appears to be exclusive to Terminal (or at least it's the only one that I have tested that has that issue) and it wasn't there in 1.18.10301.0. That being said, if the speed with which terminal is rendering text has gone up relative to the speed of resolution (which has probably stayed constant) then I can see how that would be an issue. If so, is there a way to... maybe throttle down the speed with which terminal renders? Maybe that can be tuned to solve the issue?

@marovira commented on GitHub (Dec 2, 2024): I don't think the resolution of executable paths is to blame here, at least not when running ZSH in Git bash and certainly not when it's running on a Linux server. As I mentioned in my previous reply, the flickering issue appears to be exclusive to Terminal (or at least it's the only one that I have tested that has that issue) and it wasn't there in 1.18.10301.0. That being said, if the speed with which terminal is rendering text has gone up relative to the speed of resolution (which has probably stayed constant) then I can see how that would be an issue. If so, is there a way to... maybe throttle down the speed with which terminal renders? Maybe that can be tuned to solve the issue?
claunia commented 2026-01-31 01:33:58 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Dec 2, 2024):

I don't think the resolution of executable paths is to blame here, at least not when running ZSH in Git bash and certainly not when it's running on a Linux server.

The reason I brought it up is because I think it's a good hint as to what's going on. Right now, it's still unclear if the issue is the rendering, because I haven't finished investigating the issue yet (this isn't the only issue I'm working on). This is particularly true because this issue started off being about bash and not zsh.

That being said, if the speed with which terminal is rendering text has gone up relative to the speed of resolution (which has probably stayed constant) then I can see how that would be an issue.

Both have gone up significantly over the last two years (Windows Terminal Preview is one of the fastest terminals now). If the hypothesis of too frequent stdout flushing is true, then this is what exacerbates the issue.

If so, is there a way to... maybe throttle down the speed with which terminal renders? Maybe that can be tuned to solve the issue?

I'd be against that. I prefer two ways to go about this:

  • Find a bug in our code and fix it.
  • Otherwise, improve whatever software causes the issue. Most slow VT applications are slow for no good reason.

I hope it's the former, but it's difficult to figure out what it could be, in particular because it simply doesn't happen to me in my day-to-day work.

...the only exception is when I use btop over SSH and open the options menu. That causes its menu to flicker really badly in Windows Terminal. But I know why that happens, and it's the exact issue I mentioned above: Too frequent flushing. The output arrives in two different WriteConsoleA calls per frame (roughly 10kB each). I suspect it's due to SSH and not due to btop (I believe SSH uses a 16KiB buffer size?).

@lhecker commented on GitHub (Dec 2, 2024): > I don't think the resolution of executable paths is to blame here, at least not when running ZSH in Git bash and certainly not when it's running on a Linux server. The reason I brought it up is because I think it's a good hint as to what's going on. Right now, it's still unclear if the issue is the rendering, because I haven't finished investigating the issue yet (this isn't the only issue I'm working on). This is particularly true because this issue started off being about bash and not zsh. > That being said, if the speed with which terminal is rendering text has gone up relative to the speed of resolution (which has probably stayed constant) then I can see how that would be an issue. Both have gone up significantly over the last two years (Windows Terminal Preview is one of the fastest terminals now). If the hypothesis of too frequent stdout flushing is true, then this is what exacerbates the issue. > If so, is there a way to... maybe throttle down the speed with which terminal renders? Maybe that can be tuned to solve the issue? I'd be against that. I prefer two ways to go about this: * Find a bug in our code and fix it. * Otherwise, improve whatever software causes the issue. Most slow VT applications are slow for no good reason. I hope it's the former, but it's difficult to figure out what it could be, in particular because it simply doesn't happen to me in my day-to-day work. ...the only exception is when I use `btop` over SSH and open the options menu. That causes its menu to flicker really badly in Windows Terminal. But I know why that happens, and it's the exact issue I mentioned above: Too frequent flushing. The output arrives in two different `WriteConsoleA` calls per frame (roughly 10kB each). I suspect it's due to SSH and not due to btop (I believe SSH uses a 16KiB buffer size?).
claunia commented 2026-01-31 01:33:58 +00:00
Author
Owner
Copy Link

@marovira commented on GitHub (Dec 3, 2024):

Fair enough. If you need me to try anything, let me know!

@marovira commented on GitHub (Dec 3, 2024): Fair enough. If you need me to try anything, let me know!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-TerminalControl Area-WPFControl Help Wanted Issue-Bug Priority-3 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8616
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?