I'm using VIM to edit files over SCP, so reading and writing files is a very slow process.
For some reason, whenever I switch to a buffer, VIM reads it from disk. The status bar says: ~#k.
I've disabled all autocommands in my .vimrc, and I have no autocommands for BufEnter anyway. Any idea what I might be missing?
Update: I found one culprit, a word-count macro which wasn't an auto-command. Now when I switch it's a tad faster but still slow. Status bar says ^Ww.
Update 2: I tried ZyX's answer below (Thanks!!). The results:
1) setting eventignore=all absolutely solves it; it's blazing fast. BUT
2) trying to debug it doesn't work for me.
I tried both :debug buffer scp-buffer-name and :debug wincmd p and got:
Entering Debug mode. Type "cont" to continue.
cmd: wincmd p
line 1: for m in filter(copy(fuf#getModeNames()), 'fuf#{v:val}#requiresOnCommandPre()')`
And then no matter what I typed (s, n, "cont"), that single line would just repeat. It's obviously related to the Fuzzy Finder plugin, which I do use quite a lot and is a key reason for me to use VIM. Any ideas?
Thanks again for your help. Much appreciated, XyZ!
ISSUE SOLVED: It was indeed Fuzzy Finder. It has a MRU-File mode which documentation notes may cause a performance issue when switching buffers. I disabled this mode and now VIM is fast again! Thanks!
First, test this behavior with set eventignore=all. If the problem gets fixed, try to switch to scp buffer using (be sure you have unset eventignore) debug buffer scp-buffer-name or debug wincmd p (depending on when you see the problem), it will open debug mode and you will be able to see all autocommands it is executing (use s[tep] or n[ext] to move to next command, see :h >next and :h >step for more details).
Related
It seems like almost every time I open a file in Vim anymore, I'll get an error like this:
Error detected while processing /Users/me/.vim/view/=+something=+something=+something...
E518: Unknown option: nomacmeta
The option is usually something different depending on the file. I've done :help view but the results weren't very helpful. Is there some way I can disable this view feature so I can stop getting these errors? I don't have time to run down every one of them.
:help 'macmeta' is an option specific to MacVim. You are having this error because you are sourcing a view script that contains the command set nomacmeta in a Vim that is not MacVim and thus doesn't support that option.
Either…
you are on a Mac but you are using the built-in Vim at /usr/bin/vim, which is not MacVim,
or you are on a Mac but you are using a manually built Vim, which is very likely to not be MacVim,
or you are on some other system where Vim is pretty much guaranteed to not be MacVim.
To prevent those errors, remove any non-cross-platform option from your view scripts and consider reading :help :mkview carefully, specially the part about :help 'viewoptions'.
Also, &macmeta is disabled by default so disabling it doesn't make much sense to begin with.
I am working with vim on debian.
When I press ctrl-] vim beeps, inserts a new line and goes to "visual block". It does not jump to tag. The same happens with :ctrl-]. Even in insert-mode with ctrl-] vim exits from insert-mode, insert new line and goes to 'visual block'.
But when I use such lines in .vimrc
nnoremap <F3> <c-]>
vnoremap <F3> <c-]>
jumping with F3 works.
Command :verbose map c-] returns No mapping found
update:
As we have discovered in insert mode we can see how vim is interpreting <c-]>. In insert mode after <c-V><c-]> the correct output should be ^] . But my output is
t
^C
Screenshots: after <c-v> I get
And after <c-v><c-]> .
So vim isn't receiving the keystrokes properly. How to check what changes input?
try running vim -u NONE to check if that's happening without any configuration, that way you can be sure it's not a mapping or misconfiguration.
if that solves the issue, check your vim configuration!
Also try doing it in gvim and gvim -u NONE to narrow down the issue to what it's very likely to be. If that works it's a shell or terminal misconfiguration.
if it still fails in the windowed GUI of vim, that means this is X that is wrong, try using xev to see what your key outputs, and xmodmap to printout the values assigned to all your keys on your keyboard layout.
Try using another terminal (like urxvt, gnome-terminal, xterm or the raw linux console), to determine whether it's a terminal emulator misconfiguration of your keys or if it's your shell.
if it's your terminal emulator, then get through the configuration or reset its configuration, there's something setup that shouldn't have been.
Try changing shell to see if that improves (by I doubt it will)… And add the following configuration files in your home directory:
.inputrc
Tab: complete
set meta-flag on
set input-meta on
set output-meta on
set convert-meta off
If that's not enough, you might want to check as well you stty settings for your current shell as well.
If none of that helps, then… take a big hammer and hit very hard your keyboard and your computer, that won't solve your situation, but you'll feel better!
HTH
In my vim and gvim the memory for previous buffer is not functioning properly. It did work well before but I cannot say when it started to misbehave.
If I have opened more than 2 files as buffers in one vim session, the command :b# always gets me back to the buffer which I have opened first (instead of getting me back to the previous buffer).
What might be the reason for this?
Interesting enough, if I delete a buffer, then:b# restores it.
I am on Ubuntu 14.04, my vim version is 7.4.52 and I have installed the bufexplorer plugin.
You should be using the bufexplorer issue tracker. To point you in the right direction; read :h edit-intro, specifically :h keepalt. Then take a look at the bufexplorer source code.
I've got the (Mac)Vim Syntastic plugin installed via Janus. When I open the :Errors window to view the reason for syntax errors, it shrinks the file with the errors to one line and uses the rest of the real estate for the Errors window.
Is there a way to make it hog less room for errors and more importantly, how do I close just the Errors window? The usual :q closes both the Errors window AND the original file, even if the cursor is in the Errors window. (That's not 100% correct -- it gratefully does not close the file if the file hasn't yet been saved).
Syntastic uses the location list (a window-local variant of the quickfix list), so a :lclose will close it, but keep the other buffers.
As per syntastic's help pages, the initial height can be configured:
:let g:syntastic_loc_list_height=5
But I suspect that your intrusive Janus distribution has a hand in that. Vim "distributions" like spf-13 and Janus lure you with a quick install and out of the box settings, but you pay the price with increased complexity (you need to understand both Vim's runtime loading scheme and the arbitrary conventions of the distribution) and inflexibility (the distribution may make some things easier, but other things very difficult). Vim is incredibly customizable, using someone else's customization makes no sense.
The command to close the Syntastic error window is:
:SyntasticReset
Syntastic gets confused when you're juggling multiple buffers on one screen so here's a script that will collect information about the situation, then do the right thing:
function JustCloseSyntasticWindow()
"Check which buffer we are in, and if not, return to the main one:
if &ft == "qf"
normal ZZ
endif
"Since different buffers have different command spaces, check if we've
"escaped the other buffer and then tell syntastic to stop.
if &ft != "qf"
SyntasticReset
" --- or ----
SyntasticToggleMode
endif
endfunction
au FileType buffer1_ft nnoremap :yourcmd<CR>:call JustCloseSyntasticWindow()<cr>
au FileType main_win_ft nnoremap :yourcmd<CR>:call JustCloseSyntasticWindow()<cr>
Don't be shy on the duct tape for this job, it's the only thing holding the unit together.
You can use :lclose to close it.
When running conque in VIM, the warning message prompts out every time:
Warning:
Global CursorHoldI and CursorMovedI autocommands may cause ConqueTerm to run slowly
I found a method to remove the warning is to comment out the warning-function in the conque_term.vim, but I don't think it's a decent and safe way to solve the problem.
I'm new with VIM, so I found no way to identify the source of problem by myself. Could anyone help? Thanks a lot!
One integration point into Vim is through events, which can trigger automatic commands; the Conque plugin itself uses these to implement its functionality. Events like CursorMovedI are fired whenever you type something or move the cursor in insert mode; this can have an impact on performance, and that's what the warning is about.
You can list all such automatic commands via:
:verbose autocmd CursorHoldI,CursorMovedI
As long as Conque works well for you, it's fine to ignore (and suppress) the warning. But if you indeed run into problems, you'd need to check the other autocmd sources and maybe disable one or the other plugin (at least for the Conque buffer). (See :help autocmd-remove for how to do this.)
Off topic, but using Ctrl+Z to drop back to shell and fg to return to vim seems to work way better than Conque. That is if you're using vim from the terminal, which you should.
Some inspiration: http://statico.github.com/vim.html