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

[slangreck]

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:

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".

[DHowett]

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.

[zadjii-msft]

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.

[slangreck]

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

[jdrouhard]

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?

[slangreck]

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.

[arminveres]

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

[Vyogami]

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

[SimulShift]

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

[marovira]

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.

[lhecker]

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.