Re: gvim crash after closing: gvim hanging in Windows XP Taskmanager
Hi vimmers I have some news about the crash. 1) Minimal requirement to build a gvim.exe that crashes with Microsoft Visual Studio 2005 Express Edition (VSEE): nmake -f Make_mvc.mak FEATURES=NORMAL GUI=yes OLE=yes \ MBYTE=no IME=no GIME=no SNIFF=yes CSCOPE=no \ ICONV=no GETTEXT=no POSTSCRIPT=no That means: gvim.exe has the problem only if all three following conditions are met: a) OLE=yes b) SNIFF=yes c) Close gvim.exe only after 15 minutes Sometimes, gvim seems to close properly, but in the Taskmanager one can see that gvim is yet there. 2) One can also build a huge debug version of vim and enable much more feature to let gvim show this behaviour. 3) The crash happens as follows: Within the source file src/os_mswin.c the function mch_exit() is called as soon as you press :q within gvim.exe. Now, the function UninitOLE(), defined in src/if_ole.c, called. This function calls the Windows API function OleUninitialize(), which alas never returns. I don't know how to find out where the problem is. Perhaps, there are some resources yet occupied, or some messages in a message queue of some hidden window, that leads OleUninitialize() to stop the whole program -- I'm not a specialist for such things. 4) Why does this happen only after gvim was running for 10 minutes or more? Perhaps this also depends on a time constant of the operating system: I had read somewhere that Windows unloads all 10 minutes some dlls that seam to not be in use any more. My work around: Don't use the SNIFF feature on Windows. Apropos SNIFF: The source file if_sniff.c is missing in the pc source package ftp://ftp.vim.org/pub/vim/pc/vim70src.zip. I got it from ftp://ftp.vim.org/pub/vim/extra/vim-7.0-extra.tar.gz. As mentioned in http://groups.yahoo.com/group/vimdev/message/43780, I'm not sure if that has a reason or not. Strange coincidence! With best regards Mathias
Patch (unofficial): Create PDBs and EXEs within same directory
Patch Problem:IMHO .pdb files should reside in the same directory as the corresponding .exe files so they can be distributet along with them. Solution: Change one line within src/Make_mvc.mak Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-06-04 18:09:36.210426300 +0200 --- src\Make_mvc.mak2006-06-05 19:02:19.844152000 +0200 *** *** 683,689 # on a crash (doesn't add overhead to the executable). # CFLAGS = $(CFLAGS) /Zi /Fd$(OUTDIR)/ ! LINK_PDB = /PDB:$(OUTDIR)/$(VIM).pdb -debug # -debug:full -debugtype:cv,fixup # # End extra feature include --- 683,689 # on a crash (doesn't add overhead to the executable). # CFLAGS = $(CFLAGS) /Zi /Fd$(OUTDIR)/ ! LINK_PDB = /PDB:$(VIM).pdb -debug # -debug:full -debugtype:cv,fixup # # End extra feature include -- Thanks a lot for the VIM Editor! Greetings Mathias
Re: Buffer local mappings broken in vim7?
On Thu, Jun 08, 2006 at 06:05:51PM -0600, Christian J. Robinson wrote: On Fri, 9 Jun 2006, Edwin Steiner wrote: I see a strange behaviour for buffer mappings in vim 7. Vim seems to change such mappings to select-mode mappings when the buffer is deleted, and then re-opened. I can confirm this behavior, although it's not that Vim 7 is changing the mapping, it just appears that it's clearing all but the select mode mapping from memory since :map creates a visual/select mode mapping (see :help mapmode-nvo). I found the cause in the vim source. The problem is this: #define MAP_ALL_MODES 0x3f/* all mode bits used for mapping */ It does not include SELECTMODE, which is #define SELECTMODE 0x1000 /* Select mode, only for mappings */ I don't know the vim source enough to tell if changing it to #define MAP_ALL_MODES 0x103f /* all mode bits used for mapping */ is valid. -Edwin
Re: New feature: bind layout of windows to keys?
:help tabpage.txt See also :h mksession .. That is was ZoomWin.vim (from Charles E. Campbell) is using.. You can get it on vim.org Marc
Patch (unofficial): Synchronize documetation of Makefile with my patched src/Make_mvc.mak (Thanks to Ylia)
Patch 7.0.Makefile Problem:IMHO .pdb files should reside in the same directory as the corresponding .exe files so they can be distributet along with them. Therefore, one of my recent patches adopted src/Make_mvc.mak to that opinion. Alas, now the top level Makefile is out of sync. Solution: Change documentation within ./Makefile (thanks to Ilya ilya at po4ta dot com) Files: ./Makefile *** ..\vim-7.0.000\Makefile 2006-05-07 14:16:24.0 +0200 --- .\Makefile 2006-06-09 17:34:43.712491200 +0200 *** *** 132,151 # - nmake -f Make_mvc.mak # - rm testdir/*.out, nmake -f Make_mvc.mak test and check the output. # - Rename the executables to vimw32.exe, xxdw32.exe. ! # - Rename ObjC/vim.pdb to vimw32.pdb. # - When building the Win32s version later, delete vimrun.exe, install.exe and # uninstal.exe. Otherwise rename executables to installw32.exe and # uninstalw32.exe. # Win32 GUI version: # - nmake -f Make_mvc.mak GUI=yes. # - move gvim.exe to here (otherwise the OLE version will overwrite it). ! # - Move ObjG/gvim.pdb to here. # - Delete vimrun.exe, install.exe and uninstall.exe. # - Copy GvimExt/gvimext.dll to here. # Win32 GUI version with OLE, PERL, TCL, PYTHON and dynamic IME: # - Run src/bigvim.bat (nmake -f Make_mvc.mak GUI=yes OLE=yes IME=yes ...) # - Rename gvim.exe to gvim_ole.exe. ! # - Rename ObjGOLYTR/gvim.pdb to gvim_ole.pdb. # - Delete install.exe and uninstall.exe. # - If building the Win32s version delete vimrun.exe. # Win32s GUI version: --- 132,151 # - nmake -f Make_mvc.mak # - rm testdir/*.out, nmake -f Make_mvc.mak test and check the output. # - Rename the executables to vimw32.exe, xxdw32.exe. ! # - Rename vim.pdb to vimw32.pdb. # - When building the Win32s version later, delete vimrun.exe, install.exe and # uninstal.exe. Otherwise rename executables to installw32.exe and # uninstalw32.exe. # Win32 GUI version: # - nmake -f Make_mvc.mak GUI=yes. # - move gvim.exe to here (otherwise the OLE version will overwrite it). ! # - Move gvim.pdb to here. # - Delete vimrun.exe, install.exe and uninstall.exe. # - Copy GvimExt/gvimext.dll to here. # Win32 GUI version with OLE, PERL, TCL, PYTHON and dynamic IME: # - Run src/bigvim.bat (nmake -f Make_mvc.mak GUI=yes OLE=yes IME=yes ...) # - Rename gvim.exe to gvim_ole.exe. ! # - Rename gvim.pdb to gvim_ole.pdb. # - Delete install.exe and uninstall.exe. # - If building the Win32s version delete vimrun.exe. # Win32s GUI version: -- Thanks a lot for the VIM Editor! Greetings Mathias
Re: New feature: bind layout of windows to keys?
I found that the contents of a particular ordinal tab number was too
fluid to be of much use to me, so I concentrated on making relative
navigation easier, but I could be alone in that.
The way it stands, you can make a macro sequence from inside the script using:
{m}isc menu - {ma}cro keys
... from key: S-F1
... to keys: :1 tabnextCR
using the (: ex command passthrough).
SImilarly, outside the script,
nnoremap S-F1 :1 tabnextCR
accomplishes the same thing.
On 6/8/06, Markus Mottl [EMAIL PROTECTED] wrote:
On 6/8/06, Ilya [EMAIL PROTECTED] wrote:
There is tabs in vim 7.0. They are almost exactly what you are talking
about, except that, IIUC, there is no binding to a key. But it is
possible, that some scripts could help.
:help tabpage.txt
Thanks a lot for this hint, this is pretty much what I was looking
for. I hadn't installed vim 7.0 yet so I didn't know that this
feature is already available. Great stuff! Having some default way
to bind tabs to keys (similar to storing buffer positions) would be
great, too, but I'm already quite happy with the current feature.
Regards,
Markus
--
Markus Mottlhttp://www.ocaml.info[EMAIL PROTECTED]
Re: New feature: bind layout of windows to keys?
Eric Arnold wrote:
I found that the contents of a particular ordinal tab number was too
fluid to be of much use to me, so I concentrated on making relative
navigation easier, but I could be alone in that.
The way it stands, you can make a macro sequence from inside the
script using:
{m}isc menu - {ma}cro keys
... from key: S-F1
... to keys: :1 tabnextCR
using the (: ex command passthrough).
SImilarly, outside the script,
nnoremap S-F1 :1 tabnextCR
accomplishes the same thing.
IIUC, gt is the same as S-F1 after :nnoremap S-F1 :1 tabnextCT
Re: New feature: bind layout of windows to keys?
On 6/9/06, Ilya [EMAIL PROTECTED] wrote:
Eric Arnold wrote:
I found that the contents of a particular ordinal tab number was too
fluid to be of much use to me, so I concentrated on making relative
navigation easier, but I could be alone in that.
The way it stands, you can make a macro sequence from inside the
script using:
{m}isc menu - {ma}cro keys
... from key: S-F1
... to keys: :1 tabnextCR
using the (: ex command passthrough).
SImilarly, outside the script,
nnoremap S-F1 :1 tabnextCR
accomplishes the same thing.
IIUC, gt is the same as S-F1 after :nnoremap S-F1 :1 tabnextCT
I don't think so, as gt is move to next tab, whereas tabnext 1
and 1 tabnext move to {count} tab number, not next {count} number
of tabs.
