Try such to make sure its not any VimL code or non standard
configuration.
vim -u NONE -U NONE -N
If it is Vim code gdb will be very awkward to solve your issue.
Then you have to enable/disable your plugins or code snippets to see
which is causing the issue.
If it is not VimL you may also use strace to see what vim is actually
doing (causing 100% CPU).
If it is not VimL try to start gvim without X:
DISPLAY= gvim
(by not setting DISPLAY gvim will start as vim and show an error
message)
to verify it is related to the 'gui' feature.
Looking into gdb output and the process list:
name 8139 0.7 1.0 906440 32596 pts/25 Tsl+ Oct11 173:59 /usr/bin/gvim -f
name 7661 0.0 0.0 0 0 ? Zs 07:50 0:00 \_ [bash] <defunct>
I would think the problem was with launching an external program rather than with the VimL instructions. I have "n" remapped though, but probably not "zz", ":", nor have I any affecting command line mappings or abbreviations. Perhaps "bash -c" or "php -r" crashed for some reason. I am trying to reproduce it without plugins in a separate instance with your tips, but I would rather discover a way how recover a hanging session in general even in a hackish way rather than isolate a bug in this case. My version is not the up-to-date. Attaching with gdb at least made my processor quieter by stopping the execution, so I can leave it alone for a bit.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment