Blank VIM window from Windows Command Prompt #711

TaleTN · 2016-03-30T09:15:47Z

After updating to v2.8.0 64-bit (git version 2.8.0.windows.1) VIM doesn't seem to work anymore from the Windows Command Prompt. If I e.g. try to edit a commit message I just get a blank (black) terminal window. Pressing Esc a couple of times seems to make it display a single line at the bottom of the window saying something like:

"C:/foo/.git/COMMIT_EDITGMSG" [converted][unix] 14L, 280C

Sometimes (I am not sure how/why) the VIM commit editor window does appear, but without the usual syntax highlighting, and it doesn't seem to respond to any of the usual keyboard commands.

Note that from the Git Bash terminal everything seems to work fine. Rolling back to Git v2.7.4 also seems to fix the issue, but if I then reinstall v2.8.0 the issue returns.

I am running Win10 Pro x64. I haven't installed any additional components, I use Git from the Windows Command Prompt, for Git Bash I use MinTTY, and I haven't enabled file system caching nor Git Credential Manager.

nguymin4 · 2016-03-30T11:02:23Z

@TaleTN Same issue on Window 10 x64.

I found out that, vim run smoothly when starting it with git-bash.exe. But with bash.exe, it starts really slowly and usually breaks.

dscho · 2016-03-30T12:25:40Z

Could you test whether this problem occurs also with MSYS2?

TaleTN · 2016-03-30T12:50:29Z

Sure. Well, at least I can try... I have just installed msys2-i686-20160205.exe, and then reinstalled Git v2.8.0. Basically this seems to work i.e. I see a commit message with correct syntax highighting, but I can't save my message or quit VIM (the Insert key doesn't seem to work, :x doesn't seem to work, etc.). But I also get this with Git v2.7.4 in the MSYS2 Shell, so I guess I simply don't know how VIM works under MSYS2.

chriscollinsboxuk · 2016-03-30T13:19:58Z

I've just updated to 2.8 and I'm seeing the same issue.

I see a blank window when running git commit from a:

cmd prompt
cmd prompt inside ConEmu
git bash prompt inside ConEmu
MinGW prompt

I see the VIM interface as normal when starting Git bash from the start menu. I'm on Windows 10 64 bit.

lennylxx · 2016-03-30T13:23:51Z

+1, using Windows 10 64 bit, version 1511, build 10586.164.
I replaced the vim binaries of older version, but it's doesn't work.
Downgraded to 2.7.4.

dscho · 2016-03-30T14:47:37Z

Sure. Well, at least I can try... I have just installed msys2-i686-20160205.exe, and then reinstalled Git v2.8.0.

@TaleTN well, what I meant is: does vim work in MSYS2. I.e. when you installed MSYS2 and ran pacman -Syu vim and then ran C:\msys64\usr\bin\bash.exe -l -i, does vim still freeze? (Of course I could test this myself, but my plate is real full...)

TaleTN · 2016-03-30T15:15:50Z

Oh I see... I have just reinstalled MSYS2 (64-bit this time), and then did as you said, and I think it works as expected (i.e. I see a text file, and I can exit using :x, but I can't seem to switch to insert mode; PEBKAC I guess).

dscho · 2016-03-30T15:22:40Z

@TaleTN okay, what if you replace usr\bin\msys-2.0.dll in Git for Windows with MSYS2's version? Does it fix the problem?

TaleTN · 2016-03-30T15:36:26Z

@dscho No, it does not.

koraktor · 2016-03-31T04:28:08Z

I’m having the same problem on Windows 7 (64 bit) as well since upgrading to 2.8.0.windows.1.
I’m usually using it in combination with ConEmu and Bash, but the problem is also occurring in cmd.exe.
The only option that worked for me is using the plain git-bash.exe. The only difference I can tell is that it’s not sourcing .profile et al. Disabling those configs for my normal setup does not work, though.

According to this Git mailing list posting the problem seems to be fixed when using a default vim.exe from vim.org. I didn’t try that, yet.

csmager · 2016-03-31T10:52:45Z

I'm also having the same issue (Windows 10 x64, Git for Windows 2.8.0).

I can confirm that overwriting vim.exe in Program Files\Git\usr\bin with the one included in the latest vim 7.4 package as suggested in the message linked to by @koraktor does resolve the problem.

I also noticed in my trials and error that removing set nocompatible from vimrc in Program Files\Git\etc does allow it to start and behave (reasonably) normally.

dscho · 2016-03-31T13:17:35Z

I also noticed in my trials and error that removing set nocompatible from vimrc in Program Files\Git\etc does allow it to start and behave (reasonably) normally.

Thanks for this hint. Unfortunately, it does not fix it in my case...

dscho · 2016-03-31T13:58:32Z

So far, I only found that recompiling vim does not change a thing (not very surprising, given that the vim of Git for Windows v2.7.4 still worked, and it is exactly the same vim version as v2.8.0 ships).

However, replacing msys-2.0.dll with the version from 2.7.4 does fix the problem.

jfcherng · 2016-03-31T14:10:45Z

Sadly, replacing msys-2.0.dll from Git-2.7.4-32-bit.exe gives me a start-able vim but not a usable vim. It responses pretty slowly.

dscho · 2016-03-31T15:40:24Z

@jfcherng Replacing msys-2.0.dll breaks many more things than just some aspects of vim.exe (and for future record, your statement is awfully vague, you might want to step up the precision and detail in future comments). For example, ls.exe exits with exit code 127, indicating a DLL problem (indeed, a symbol expected by ls.exe is not found in that version). The point of my remark was to indicate that the problem was not introduced by vim, but by an upgrade in the msys2-runtime. And while we are speaking, I am bisecting the issue to get closer to the root cause. I am keeping you updated as a matter of courtesy.

brezanac · 2016-03-31T15:53:23Z

Windows 8.1 x64. Git for Windows 2.8.0 breaks Vim (7.4.1468) when used with cmder (ConEmu) but it does work fine with Mintty. Running vim just opens a blank screen initially and it takes some time and a couple of keypresses for vim to actually appear. Exiting is however impossible.

dscho · 2016-03-31T16:04:31Z

Git for Windows 2.8.0 breaks Vim (7.4.168)

Did you mean 7.4.1_4_68?

brezanac · 2016-03-31T16:06:58Z

Did you mean 7.4.1468?

Yes, my bad. A typo. It's vim 7.4.1468.

dscho · 2016-03-31T16:08:57Z

Progress: turns out that git-for-windows/msys2-runtime@7346568 might be the problematic change.

dscho · 2016-03-31T16:12:50Z

Indeed, the culprit is git-for-windows/msys2-runtime@7346568 and reverting it fixes the issue. Will continue tomorrow.

TaleTN · 2016-03-31T16:26:37Z

@dscho That sounds very promising. Thanks!

dscho · 2016-04-01T06:19:47Z

Uploaded into the Pacman repository of the Git for Windows SDK.

You can fix it locally by downloading https://dl.bintray.com/git-for-windows/pacman/x86_64/msys2-runtime-2.4.1.34115.1ca92fa-1-x86_64.pkg.tar.xz and extracting usr\bin\msys-2.0.dll into your existing Git for Windows.

[EDIT: fixed the link as pointed out by @mmalolepszy; Thanks!]

mmalolepszy · 2016-04-01T06:31:08Z

The link above doesn't work. This one should: https://dl.bintray.com/git-for-windows/pacman/x86_64/msys2-runtime-2.4.1.34115.1ca92fa-1-x86_64.pkg.tar.xz

moosekaka · 2016-04-01T10:15:44Z

I can confirm that it fixes the issue after running pacman -Syuu. Thank you!

In 7346568 (Make requested console reports work, 2016-03-16), code was introduced to report the current cursor position. It works by using a pointer that either points to the next byte in the readahead buffer, or to a NUL byte if the buffer is depleted, or the pointer is NULL. These conditions are heeded in the fhandler_console::read() method, but the condition that the pointer can point at the end of the readahead buffer was not handled properly in the get_cons_readahead_valid() method. This poses a problem e.g. in Git for Windows (which uses a slightly modified MSYS2 runtime which is in turn a slightly modified Cygwin runtime) when vim queries the cursor position and immediately goes on to read console input, erroneously thinking that the readahead buffer is valid when it is already depleted instead. This condition results in an apparent freeze that can be helped only by pressing keys repeatedly. The full Git for Windows bug report is here: git-for-windows/git#711 Let's just teach the get_cons_readahead_valid() method to handle a depleted readahead buffer correctly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This fixes git-for-windows/git#711 This reverts commit 7346568. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This is the proper fix for git-for-windows/git#711 It is actually a real bug fix that will be submitted to Cygwin momentarily. Revert "Revert "Make requested console reports work"" This reverts commit a08308b.

In 7346568 (Make requested console reports work, 2016-03-16), code was introduced to report the current cursor position. It works by using a pointer that either points to the next byte in the readahead buffer, or to a NUL byte if the buffer is depleted, or the pointer is NULL. These conditions are heeded in the fhandler_console::read() method, but the condition that the pointer can point at the end of the readahead buffer was not handled properly in the get_cons_readahead_valid() method. This poses a problem e.g. in Git for Windows (which uses a slightly modified MSYS2 runtime which is in turn a slightly modified Cygwin runtime) when vim queries the cursor position and immediately goes on to read console input, erroneously thinking that the readahead buffer is valid when it is already depleted instead. This condition results in an apparent freeze that can be helped only by pressing keys repeatedly. The full Git for Windows bug report is here: git-for-windows/git#711 Let's just teach the get_cons_readahead_valid() method to handle a depleted readahead buffer correctly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

seanzer · 2017-05-30T15:14:45Z

Is this fix released in git 2.13.0? I'm still having problems

TaleTN · 2017-05-30T15:59:28Z

I am on 2.13.0 also, and everything seems fine here. BTW, I think this specific issue was fixed in 2.8.1, and I haven't seen the issue again since, so maybe what you are seeing is another issue?

dscho closed this as completed in git-for-windows/msys2-runtime@1ca92fa Mar 31, 2016

TaleTN mentioned this issue Apr 2, 2016

Vim integration broke with 2.8 release #716

Closed

1 task

danielwagn3r mentioned this issue Apr 4, 2016

VIM not working on Windows since Git 2.8.0 for Windows git/git-scm.com#725

Closed

dscho added a commit to git-for-windows/msys2-runtime that referenced this issue Apr 5, 2016

Revert "Make requested console reports work"

a08308b

This fixes git-for-windows/git#711 This reverts commit 7346568. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

angularsen mentioned this issue Apr 6, 2016

VI/VIM very unresponsive after upgrading to Git 2.8.0.windows.1 Maximus5/ConEmu#618

Closed

nathanhi mentioned this issue Apr 6, 2016

Vim freezes on startup vim/vim#730

Closed

seanzer mentioned this issue May 30, 2017

git commit hangs #1187

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Blank VIM window from Windows Command Prompt #711

Blank VIM window from Windows Command Prompt #711

TaleTN commented Mar 30, 2016

nguymin4 commented Mar 30, 2016

dscho commented Mar 30, 2016

TaleTN commented Mar 30, 2016

chriscollinsboxuk commented Mar 30, 2016

lennylxx commented Mar 30, 2016

dscho commented Mar 30, 2016

TaleTN commented Mar 30, 2016

dscho commented Mar 30, 2016

TaleTN commented Mar 30, 2016

koraktor commented Mar 31, 2016

csmager commented Mar 31, 2016

dscho commented Mar 31, 2016

dscho commented Mar 31, 2016

jfcherng commented Mar 31, 2016

dscho commented Mar 31, 2016

brezanac commented Mar 31, 2016

dscho commented Mar 31, 2016

brezanac commented Mar 31, 2016

dscho commented Mar 31, 2016

dscho commented Mar 31, 2016

TaleTN commented Mar 31, 2016

dscho commented Apr 1, 2016

mmalolepszy commented Apr 1, 2016

moosekaka commented Apr 1, 2016

seanzer commented May 30, 2017

TaleTN commented May 30, 2017

Blank VIM window from Windows Command Prompt #711

Blank VIM window from Windows Command Prompt #711

Comments

TaleTN commented Mar 30, 2016

nguymin4 commented Mar 30, 2016

dscho commented Mar 30, 2016

TaleTN commented Mar 30, 2016

chriscollinsboxuk commented Mar 30, 2016

lennylxx commented Mar 30, 2016

dscho commented Mar 30, 2016

TaleTN commented Mar 30, 2016

dscho commented Mar 30, 2016

TaleTN commented Mar 30, 2016

koraktor commented Mar 31, 2016

csmager commented Mar 31, 2016

dscho commented Mar 31, 2016

dscho commented Mar 31, 2016

jfcherng commented Mar 31, 2016

dscho commented Mar 31, 2016

brezanac commented Mar 31, 2016

dscho commented Mar 31, 2016

brezanac commented Mar 31, 2016

dscho commented Mar 31, 2016

dscho commented Mar 31, 2016

TaleTN commented Mar 31, 2016

dscho commented Apr 1, 2016

mmalolepszy commented Apr 1, 2016

moosekaka commented Apr 1, 2016

seanzer commented May 30, 2017

TaleTN commented May 30, 2017