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