Recently, when I use vim to edit cpp file, it stucks frequently when I do "save" command.
When I use ps aux |grep vim I find the following line.
haoli 21143 1.2 0.1 217916 22212 pts/3 D+ 13:07 0:05 vim xxx.cc
D means Disk sleep. And when I run kill -9 21143, the process still exists.
Is vim stuck when saving to disk?
Who cause this bug?
Vim-plugin.
Here is my plugin list
Plugin 'VundleVim/Vundle.vim'
Plugin 'connorholyday/vim-snazzy'
Plugin 'vim-airline/vim-airline'
Plugin 'terryma/vim-multiple-cursors'
Plugin 'tpope/vim-fugitive
Plugin 'wincent/command-t'
Plugin 'scrooloose/nerdcommenter'
Plugin 'octol/vim-cpp-enhanced-highlight'
Disk
I don't know how to debug.
Related
Sometimes Vim plugins suggest a load order, but Vim nowaday natively supports loading plugins with no plugin manager. You just put a submodule in a folder such as ~/.vim/pack/vendor/start and it'll automatically load. So, my question is how do you ensure a load order similar to how people would previously. Older way of doing things example below:
Plug 'preservim/nerdtree' |
\ Plug 'Xuyuanp/nerdtree-git-plugin' |
\ Plug 'ryanoasis/vim-devicons'
Taken from https://github.com/Xuyuanp/nerdtree-git-plugin#faq.
Let's try a little experiment…
Create the following dummy files with their corresponding content:
Filepath
Content
pack/dummy/start/nerdtree/plugin/foo.vim
echom "nerdtree"
pack/dummy/start/nerdtree-git-plugin/plugin/bar.vim
echom "nerdtree-git-plugin"
pack/dummy/start/vim-devicons/plugin/baz.vim
echom "vim-devicons"
Start Vim and you should see something like the following:
$ vim
nerdtree
nerdtree-git-plugin
vim-devicons
Press ENTER or type command to continue
which is consistant with:
:filter dummy scriptnames
40: ~/.vim/pack/dummy/start/nerdtree/plugin/foo.vim
41: ~/.vim/pack/dummy/start/nerdtree-git-plugin/plugin/bar.vim
42: ~/.vim/pack/dummy/start/vim-devicons/plugin/baz.vim
Press ENTER or type command to continue
Based on this experiment, we can conclude that the built-in "package" feature will "load" plugins found in start/ in the filesystem order which happens to be the same as the prescribed order anyway. Of course, your filesystem may order directories differently than mine, so YMMV.
In theory, the :help :packadd command should allow you to "manage" your plugins from your vimrc, like you would with a plugin manager. Let's experiment with it…
Rename start/ to opt/:
pack/dummy/opt/nerdtree/
pack/dummy/opt/nerdtree-git-plugin/
pack/dummy/opt/vim-devicons/
Add the following lines to your vimrc after any syntax on or filetype on line:
packadd! nerdtree
packadd! nerdtree-git-plugin
packadd! vim-devicons
Start Vim:
$ vim
vim-devicons
nerdtree-git-plugin
nerdtree
Press ENTER or type command to continue
What?
Well… I guess you could experiment with ordering, here, until you get the desired order but that reverse order looks like a bug to me.
If I open a file in a current directory using netrw and then reopen the netrw using :Sexplore the netrw window opens below (I have splitbelow set), but the cursor remains in the file being edited and I cannot move to the netrw window using CTRL-W combinations.
Am I doing something wrong or is this a bug?
Steps to reproduce
run vim .
netrw opens, highlight a file in the current directory (let's say test.txt) and press Return, file test.txt opens
run :Sexplore cmd
netrw opens below but the cursor remains in the file opened previously.
My .vimrc
set nocompatible
set splitbelow
VIM version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 8 2015 23:11:08)
MacOS X (unix) version
Included patches: 1-944
This is how it looks like:
I cannot reproduce with version 154a (use :echo g:loaded_netrwPlugin to check your netrw version).
Try with the latest version.
Edit:
It is possible that the problem is cause by some other plugin interference or settings. You could try following the approach described at Vim FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual
runtime files or any plugin that is distributed with Vim or whether it
is a simple side effect of any configuration option from your .vimrc
or .gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
This starts Vim in nocompatible mode (-N), without reading your
viminfo file (-i NONE), without reading any configuration file (-u
NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc
file) or even plugin.
(...)
If the error does not occur when starting Vim this way, then the
problem is either related to some plugin of yours or some setting in
one of your local setup files. You need to find out, what triggers the
error, you try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load
any plugins. If the error occurs this time, the error is possibly
caused by some configuration option inside your .vimrc file. Depending
on the length of your vimrc file, it can be quite hard to trace the
origin within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half
of your .vimrc. If it doesn't happen, the problematic setting must be
in the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and
move your way along, until you find the problematic option. If your
.vimrc is 350 lines long, you need at a maximum 9 tries to find the
offending line (in practise, this can often be further reduced, since
often lines depend on each other).
Obviously you will have to load netrw manually (which can be done by sourcing plugin/netrwPlugin.vim -- if you are using some plugin manager you will have to move the plugin to ~/.vim/ or change your runtime path due to the autoload functions) and set nocompatible and splitbelow.
Actually there is an adapted version of this procedure in :help netrw-debug:
Step 2: assuming that you've installed the latest version of netrw,
check that your problem is really due to netrw. Create a file called
netrw.vimrc with the following contents:
set nocp
so $HOME/.vim/plugin/netrwPlugin.vim
Then run netrw as follows:
vim -u netrw.vimrc --noplugins [some path here]
Perform whatever
netrw commands you need to, and check that the problem is still
present. This procedure sidesteps any issues due to personal .vimrc
settings and other plugins. If the problem does not appear, then you
need to determine what setting in your .vimrc is causing the conflict
with netrw or which plugin.
Step 3: If the problem still is present, then get a debugging trace
from netrw:
(...)
I'm running gvim -u NONE to open gvim without using .vimrc, but in the same time I would like to be able to call the commands from the plugins inside the plugin/ folder.
I tried it running :filetype plugin on but it doesn't work..
Any idea how to do that?
Use -u NORC instead of -u NONE. See :help --noplugin.
I'm using MacVim (kind of gvim for OSX) and try to get the slimv plugin running.
Sadly it's not working out of the box. In fact, it does not start up at all.
My setup:
MacVim (32bit cause of this) (vim 7.3)
:scriptnames does not list ftplugin/slimv.vim while plugin/paredit.vim is listed
:set ft? shows filetype=lisp for .lisp files
:messages shows no errors
:filetype filetype detection:ON plugin:ON indent:ON
:echo g:paredit_loaded 1
:echo g:slimv_loaded E121: Undefined variable: g:slimv_loaded \ E15: Invalid expression: g:slimv_loaded
compiled with +python (2.7)
SBCL and slime are installed - works flawless with emacs.
I tried it with and without let g:slimv_swank_cmd = ... in .vimrc and changed the line recommended on the plugin page from
let g:slimv_swank_cmd = '!osascript -e "tell application \"Terminal\" to do script \"sbcl --load ~/.vim/slime/start-swank.lisp\""'
to
let g:slimv_swank_cmd = '!sh -c "sbcl --load /Applications/MacVim.app/Contents/Resources/vim/runtime/slime/start-swank.lisp" &'
since the osascript was not working and I don't know how to fix it. But a similar call to xterm is sufficient for Linux so my sh call should be fine.
Well, I got no idea what to try next. :/
The problem got solved by installing slimv to ~/.vim instead of the vim ebedded in MacVim. Maybe some kind of bug? However, Common Lisp + vim - I just love it.
Because moving the slimv plugin to ~/.vim fixed it, I suspect the problem is that MacVim's default /Applications/MacVim.app/Contents/Resources/vim/runtime/ftplugin/lisp.vim is being sourced before the ftplugin/lisp/slimv-lisp.vim file provided with slimv.
Both of those files (lisp.vim and slimv-lisp.vim) start with code like this:
" Only do this when not done yet for this buffer
if exists("b:did_ftplugin")
finish
endif
" Don't load another plugin for this buffer
let b:did_ftplugin = 1
and so whichever file gets sourced first will prevent the other file from running since vim does finish (exits the script) if it detects that another *lisp*.vim script was run previously and therefore set the b:did_ftplugin buffer-local variable.
You can tell this is happening by running MacVim from the command line with the arguments:
-V20macvim-log.txt hello.lisp
Then quit the MacVim session that starts up, and look at the macvim-log.txt file it created.
Search for b:did_ftplugin and you'll see it referenced each time lisp.vim or slimv-lisp.vim runs, and you can see that lisp.vim runs first, which prevents slimv-lisp.vim from working.
Moving your slimv install from the /Applications/MacVim.app/ dir to your ~/.vim dir will change the order so that slimv-lisp.vim is sourced before lisp.vim, and then slimv will work.
If slimv.vim is not listed in :scriptnames and g:slimv_loaded is undefined then you don't have the plugin loaded at all. I guess you don't have filetype plugins enabled. Paredit is a general plugin but slimv.vim is a filetype plugin and filetype/indent plugins must explicitly be enabled. Try to add these lines to your .vimrc:
filetype plugin on
filetype indent on
The problem got solved by installing slimv to ~/.vim instead of the vim ebedded in MacVim. Maybe some kind of bug?
However, Common Lisp + vim - I just love it.
I use pathogen and have an update script that downloads the latest versions of all the vim plugins I use from vim.org, github, or wherever else they may be. However, this script does not currently update the vim helptags. In order to do so, I have to go to each updated plugin in vim and execute ":helptags doc/". It would be great if I could do so with my update script, but in order to do so I need to run the vim ":helptags" command from a script. Is this possible?
Thanks!
pathogen.vim versions after 1.2 (2010-01-17) have a pathogen#helptags function that will automatically update the help tags for each directory in the runtimepath. Just call it after you call pathogen#runtime_append_all_bundles:
call pathogen#runtime_append_all_bundles()
call pathogen#helptags()
Or, assuming you have call pathogen#runtime_append_all_bundles() in your .vimrc:
vim -c 'call pathogen#helptags()|q'
from the command line only once after you have fetched the updates.
Recent versions of pathogen recommend calling pathogen#infect() in your .vimrc instead of pathogen#runtime_append_all_bundles (since b147125 “Add pathogen#infect() as primary entry point for basic setup”, 2011-05-13; the former calls the latter internally). If your .vimrc is calling pathogen#infect(), then put your call to pathogen#helptags() after that.
Shouldn't all of the documentation be in the same doc directory? Maybe .vim/doc, /usr/share/vim/vimfiles/doc?
In any case, you can launch vim, and direct it to run a command:
cd <plugindir>
vim -c "helptags doc/"
You can specify multiple commands, so the last one can be -c q to have vim exit when you're done. (Or you can tack it on as one command, command1 | q.) Or, if you have many commands to run, you can generate a script, and have vim run it using vim -S <script>; again, you can make the last command of the script q so it closes when it's done.
In recent enough versions, :helptags ALL will work.
For some time pathogen provides the Helptags command that updates the documentation of all your bundles (and all other directories that are part of the runtimepath).
Thus, it's sufficient to call
:Helptags
after your Vim plugin collection has changed. Possibly even automatically by calling e.g. vim -c Helptags -c q from your update script.