VIM console failure on Windows
Mike Williams
On my Windows boxes I use ConsoleZ (https://github.com/cbucher/console)
instead of the standard command or powershell prompts. Using 7.4p889
when I start console VIM I get a brief flash of the VIM interface before
it switches back to the original command line display. VIM is still
running (can be seen in task manager consuming CPU) but keyboard input
has no effect on - :q doesn't quit VIM and the command prompt doesn't
show any keyboard input. This all started with patch 851, Saving and
restoring the console buffer does not work properly.
I have checked what happens with the command and powershell shells using
ConsoleZ and there is no difference in behaviour. I am using version
1.15.0.15253 of ConsoleZ. ConsoleZ is a fork of Console
(http://sourceforge.net/projects/console/). I checked what happens with
Console version Console 2.00.148 and it behaves the same as ConsoleZ.
It may be an issue with the Console apps but I have been using both for
the last few years and until this patch have had no problems using
console VIM with them. The finger pointing has to start somewhere so
let it be here.
TTFN
Mike
--
I hate mornings. They start too early in the day.
Mike Williams
7 amd64, fully patched, with a 64bit build of VIM using VS2012, debug
and release. Build line of:
nmake -f make_mvc.mak WINVER=0x0501 DIRECTX=yes PYTHON=h:\python27
PYTHON_VER=27 DYNAMIC_PYTHON=yes
Hmm, ok, the DIRECTX=yes looks unnecessary for a console VIM. Removed
it and tried again. Still hangs, but I don't get the flash of the VIM
interface now.
HTH - TTFN
Mike
--
All the world's a stage, and I missed the rehearsal.
Bram Moolenaar
the author(s) of those patches would respond.
Possibly relevant patches:
Patch 7.4.886 Windows7: Switching screen buffer causes flicker when
using system(). Should only apply to system(). Do you have an external
command in your startup?
Patch 7.4.876 Windows7: when using vim.exe with msys or msys2,
conhost.exe (console window provider on Windows7) will freeze or crash.
Similarly, should only affect executing an external program.
Patch 7.4.851 Saving and restoring the console buffer does not work
properly. This looks like the main suspect. Can you try going to patch
7.4.850 and 7.4.851, check whether the problem is caused by this patch?
--
hundred-and-one symptoms of being an internet addict:
44. Your friends no longer send you e-mail...they just log on to your IRC
channel.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Ken Takata
It is obvious that 7.4.851 causes this problem.
When I wrote the patch, I thought that using CreateConsoleScreenBuffer and
SetConsoleActiveScreenBuffer is a perfect solution to save and restore a
console buffer, but now I think it was totally wrong because it causes many
problems.
1. The patch 7.4.851 hits a known bug on Windows 7.
- https://github.com/cbucher/console/issues/148#issuecomment-66362147
- https://fogbugz.bitvise.com/default.asp?WinSSHD.1.16969.1
- http://support.microsoft.com/kb/2458000
This is fixed with 7.4.876 and 7.4.886, but I think that it still has a
potential problem. When a vim plugin execute an external program without
using system() (e.g. using if_python, if_ruby, vimproc, etc.), crashes might
occur.
2. The patch hits another (unknown?) bug on Windows 10 when vimproc is
used.
- https://github.com/Shougo/neocomplete.vim/issues/471
- https://github.com/Shougo/vimproc.vim/issues/208
Currently, I have no idea how to fix this.
3. Some console emulators (ConsoleZ, Console2, ckw, winpty, etc.)
don't support CreateConsoleScreenBuffer and SetConsoleActiveScreenBuffer.
This is the cause of the problem which was reported by Mike.
I hope these console emulators support these APIs, but it might take long time.
(FYI, ConEmu seems to support these APIs but not perfect.)
So I propose Bram to revert 7.4.851, 7.4.876 and 7.4.886.
Regards,
Ken Takata
Ben Fritz
>
> So I propose Bram to revert 7.4.851, 7.4.876 and 7.4.886.
>
Is it only on Windows that these patches cause problems? I'm unaffected by all of this, but I know they solve a problem for many people on other systems.
Perhaps this is a place for OS-specific compilation?
Ken Takata
Yes, the patch only affects Windows.
Regards,
Ken Takata
Christian Brabandt
https://groups.google.com/d/msg/vim_dev/zul_u1oYm50/W9KXkewABwAJ
Or is this problem independent of those mentioned above?
Best,
Christian
--
Persönlichkeiten werden nicht durch schöne Reden geformt, sondern
durch Arbeit und eigene Leistung.
-- Albert Einstein
Ken Takata
I think reverting 7.4.851 fixes the problem, but not sure.
At least, I haven't seen the problem before 7.4.851.
Regards,
Ken Takata
Craig Barkhouse
> On Do, 29 Okt 2015, Ken Takata wrote:
> > It is obvious that 7.4.851 causes this problem.
> > When I wrote the patch, I thought that using
> > CreateConsoleScreenBuffer and SetConsoleActiveScreenBuffer is a
> > perfect solution to save and restore a console buffer, but now I
> > think it was totally wrong because it causes many problems.
From version6.txt:
Win32: Console version didn't work on telnet, because of switching between two
console screens. Now use one console screen and save/restore the contents
when needed. (Craig Barkhouse)