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
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'm using yats (https://github.com/HerringtonDarkholme/yats.vim) for typescript, it sets the makeprg variable, which makes it so vim runs make everytime I make a change to a file. I would like to somehow disable this, as I prefer a linter manager (ALE), which can compile and also lint.
Is there something I can do about that localy or does yats need an option to disable the setting of makeprg?
EDIT:
The accepted answer doesn't provide actual solution to my specific problem, but the explanation of makeprg guided me in the right direction, which was other plugins. I traced the problem back to YouCompleteMe.
it sets the makeprg variable, which makes it so vim runs make everytime I make a change to a file.
No, makeprg only defines what external command to run when you or a plugin does :make.
Furthermore, I couldn't find anything in that plugin that would run :make on write or on any other event. The command below will hopefully help you find where that automatic make comes from:
:verbose autocmd BufWritePost
See :help :verbose, :help :autocmd, :help BufWritePost.
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).
Sometimes I try a customization/command in my vimrc. Everything seens to be correct, but it just doesn't work.
It's difficult to know what's happening when vim starts, and know which command failed or not, so it's really difficult to debug what can be causing a problem in my vimrc. It's a trial-error approach, which is time consuming and really a PITA. For example, I'm having problems with snipmate plugin in some files and just don't have a clue on how to discover the problem.
Is there a "runtime log" when vim starts, telling which commands it executed, which ones failed and such? This would help me a lot.
running vim with the -V[N] option will do a pretty hefty runtime log, here N is the debug level.
vim -V9myVim.log
would create a log of debug level 9 in the current directory with the filename myVim.log
:messages shows all warnings, errors, and informational messages that appeared (possibly briefly) in the vim statusline.
:echo errmsg prints the most recent error message.
g< is another feature few people know about. From :help g<:
The g< command can be used to see the last page of previous command output. This is especially useful if you accidentally typed <Space> at the hit-enter prompt.
For example try :!ls then cancel the prompt, then hit g<.
Put this function into .vimrc:
function! ToggleVerbose()
if !&verbose
set verbosefile=~/.log/vim/verbose.log
set verbose=15
else
set verbose=0
set verbosefile=
endif
endfunction
Then create directory ~/.log/vim and call ToggleVerbose() to get your log in ~/.log/vim/verbose.log. Note that you may catch «variable nested too deep for displaying» error which will not normally appear just because you have raised your verbose level.
I don't think there is a runtime log, per se, but you can run it in debug mode.
http://web.archive.org/web/20090323034339/http://www.troubleshootingwiki.org/Debugging_Vim_Scripts
This probably goes against everything SO stands for, but here's what I do: I just hit print screen soon as the warning comes up and look at the picture.
I had to add "set nocp" to use "ToggleVerbose()" function when run in root because of &verbose
I have installed vimclojure to make it easier to start learning clojure. But, I haven't been able to setup REPL inside vim. This is essentially because I was not able to write a maplocalleader in vim(?)
Based on the documentation in vimclojure/doc/clojure.txt I put the following in my .vimrc to start the REPL -
:map <LocalLeader>sr *sr* *StartRepl*
But typing "sr" doesn't start the REPL.
Thanks in advance.
Most likely there is an error occurring in the plugin before the VimClojure mappings are fully defined.
One likely scenario that I have run into several times occurs when the Clojure source file has syntax errors when it's loaded into the Vim buffer.
There's something going on in the plugin during the load of the source file (syntax highlighting or something) that errors out and prevents the mappings from getting defined.
This is probably just an unfortunate issue with VimClojure and should be reported, but I haven't had time to dig enough and log an intelligent bug report/patch.
To troubleshoot, with a Clojure source file open in current buffer, try doing this:
:call vimclojure#Repl.New()
This invokes the function inside the plugin that is mapped to \sr. It's not a recommended way of launching the Repl, but since we're just troubleshooting your configuration, hopefully it will reveal something meaningful to you.
Also, do this to see if there happen to be any helpful messages getting logged.
:messages
<LocalLeader> uses value from maplocalleader variable or it is backslash by default. If you do not set maplocalleader variable try \sr
I've found vim-fireplace plugin a much easier way to start learning Clojure in Vim. Good introduction can be found in "Unboxing vim-fireplace".
I don't have a mapping for sr in my .vimrc, but it works for me.
Have you checked that your Nailgun server is running, and that you have turned on Gorilla?
E.g.,
let clj_want_gorilla = 1
let vimclojure#NailgunClient = "/Users/foo/vimclojure-2.1.0/ng"
One can use Conque, a vim plugin that supports running a shell in a vim buffer. I have successfully used it to run a clojure REPL inside vim. It supports split screens, so one can send code from a clojure source code buffer to the clojure REPL.
I've found that if the NailgunClient cannot be found, VimClojure will fail silently and none of the <LocalLeader> commands will work. I'm basically just repeating Joe Holloway above, but try this to verify that the Nailgun client is actually found:
:call vimclojure#Repl.New()
In my case I forgot to build the client, so I just returned to the unzipped VimClojure folder and ran make. This creates ng, the nailgun client executable. Make sure this is in your PATH somewhere, or set
let vimclojure#NailgunClient = "/Users/foo/vimclojure-2.1.0/ng"
as mentioned above.
Don't you need to press ,sr? LocalLeader is a comma by default I think.
Have you tried mapping it to something else? It seems like you aren't sure what LocalLeader is mapped to, so I would recommend changing your mapping.
I solved the E10 problem with :set nocompatible. Then the \sr etc. commands worked OK.
Getting VimClojure setup with a Nailgun server is how I've done it. I use leiningen to help manage the classpath. It's a fairly complicated process, but nice once you've got it set up.
In addition to using the correct local leader key (ie. "\" -> \sr by default), note that in order for VimClojure to start a repl, a clojure file needs to be loaded in the buffer. If you just start vim and hit \sr nothing will happen because VimClojure is not active yet.
You can activate VimClojure by editing a file with the clj extension. From inside vim:
:e test.clj
Now when you hit \sr the repl should open. If not, see the other answer regarding checking hidden error messages.
This tutorial is up-to-date as of time of writing and helped me get VimClojure set up with Leiningen in OSX: https://github.com/daveray/vimclojure-easy
The more advanced setup linked to in the What's Next section was also helpful.