Neovim + rainbow - vim

Asking a question here worked before about this type of issue, so I will try again.
I'm trying to use the rainbow plugin (https://github.com/luochen1990/rainbow) while learning clojure.
I do have TERM=xterm-256color set in my shell (zsh, if it matters).
I've also tried running nvim as COLORTERM=xterm-256color TERM=xterm-256color nvim
Here are my results:
vim:
nvim:
If anyone has any advice or settings to try, I'd be extremely obliged. Thanks very much!

Seems your not the only one to notice https://github.com/luochen1990/rainbow/issues/31
It looks like something doesn't work properly to activate the plugin in neovim. Adding the following to your nvimrc
let g:rainbow_active = 1
autocmd VimEnter * RainbowToggle
makes the plugin work for me.
The autocmd just forces the plugin to start. If the plugin gets updated this might make it stop working since it could toggle it off.
Second answer
After more digging it appears you only need to put the following into your nvimrc.
syntax on
let g:rainbow_active = 1
The auto command gets fired on syntax on assuming g:rainbow_active is in your nvimrc.

Related

delimitMate not working on vim installed with Pathogen

I'm trying to install delimitMate on vim version 7.3. I am using Pathogen. My other pathogen bundles work, so it is not a problem with my setup.
In fact, I've also tried auto-pairs and ClosePairs plugins too, and none of them work. I don't know why? Am I using it wrong? Shouldn't a matching paren simply follow when I put an opening paren (similar to sublime Text?)
The commands :DelimitMateTest and :h delimitemate works, so the script is being executed. It's just not actually autoclosing any parens, and I can't figure out why.
Here's the output file for :DelimitMateTest: http://pastebin.com/2WtHVZJL
Any ideas as to why I can't get paren completion from any plugin?
Thanks!
For those of you who come across this problem in the future:
I had set paste in my .vimrc. This permanently disables several other features, and it was messing up key mappings. Simply remove it from your .vimrc and you should fix your problem.

Prevent vim from autofolding when typing

Every time i use snippets in vim while coding in Python i get a problem which i desire to get rid off.
Here is the sequence of steps which leads to my problem:
type fun and hit Tab to trigger snippets of a new function
start typing to define its name.
On the last step i get all the body of my new function folded and i even don't see my cursor at the place i am currently typing.
Info:
I am using python-mode plugin which defines foldingmethod
here
I am also using ultisnips and vim-snippets.
Here is my
vimrc, which contains nothing criminal as seems to me.
How could i fix such an issue?
I had a similar issue with PHP code completion. It would automatically fold anything above a return statement as I typed.
I likewise narrowed the issue to the YCM plugin; I disabled all other plugins and set YCM options to defaults.
The issue went away when I set foldmethod to manual in my vimrc:
set foldmethod=manual

Syntax highlighting causes terrible lag in Vim

I love Vim. But its giving me hard times right now.
I use a lot of plugins and during the last 6 months, I've found a lot of awesome ones. But my Vim got really sluggish too. I do constant cleanups, but it doesn't help much.
I'm at the point, where Vim is completely unusable. It feels like it renders at 2-5 frames per second, switching tabs/buffers takes about a second, scrolling with hjkl is awfully terrible, the lag is so bad, even typing a sentence in insert mode is confusing (due to lag).
Edit: Actually, when I open fresh instance of Vim its OK-ish, but than within 15 minutes it becomes unusable.
I've just spent 4 hours trying to figure out which plugin or config is causing the pain. I was unsuccessful.
However, I did find out, that removal of this setting causes all the lag to go away:
syntax on
These 3 lines in conjunction with syntax make everything even worse.
set t_Co=256
set background=dark
colorscheme candyman
Interesting. So, syntax highlighting is turning Vim from super snappy to incredibly sluggish?
I tried enabling syntax in "clean" mode:
vim -u NONE
And its not an issue there.
So what seems to be the issue is Syntax Highlighting in combination with one or more of my plugins. I tried disabling bunch, no luck.
Is there any way to do profiling? I'm fairly exhausted from manual testing.
Has anyone had similar experience? Maybe take a quick peek into my .vimrc, see if anything rings a bell.
https://bitbucket.org/furion/dotfiles
SOLUTION:
The plugin causing the mess was:
Bundle "gorodinskiy/vim-coloresque.git"
I recommend reading the answers tho, good insights.
Edit (1 month later): The coloresque plugin has seen some improvements.
EDIT: Blogged about how this all works, with screenshots and awesome-sauce.
https://eduncan911.com/software/fix-slow-scrolling-in-vim-and-neovim.html
Original answer below...
:syntime on
move around in your ruby file and then
:syntime report
It reported the following slowest matching for me, and you can see that there are not even 1 match.
I disabled rubyPredefinedConstant in ruby.vim file and problem solved. Vim regex engine does not like something in ruby syntax highlight regex. You will have to find the balance between enough syntax highligting and a good performance.
Here is the top 3 slowest syntax highlighting regex for ruby reported on my Mac OS 10.8.5, homebrew Vim 7.4 (console vim)
TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
3.498505 12494 0 0.008359 0.000280 rubyPredefinedConstant \%(\%(\.\#<!\.\)\#<!\|::\)\_s*\zs\%(STDERR\|STDIN\|STDOUT\|TOPLEVEL_BINDING\|TRUE\)\>\%(\s*(\)\#!
2.948513 12494 0 0.006798 0.000236 rubyPredefinedConstant \%(\%(\.\#<!\.\)\#<!\|::\)\_s*\zs\%(MatchingData\|ARGF\|ARGV\|ENV\)\>\%(\s*(\)\#!
2.438253 12494 0 0.005346 0.000195 rubyPredefinedConstant \%(\%(\.\#<!\.\)\#<!\|::\)\_s*\zs\%(DATA\|FALSE\|NIL\)\>\%(\s*(\)\#!
Or you can try vim-ruby as pointed out by Dojosto
You have autocmd spam. You should wrap all of your autocmd statements in groups which clear the group before re-adding the autocmds. It looks like your .vimrc has most autocmds commented-out, so maybe there is a plugin that is causing the issue. Check the output of this command:
:au CursorMoved
If there's a bunch of duplicate handlers there, that's your problem.
Here's an example of autocmd discipline from my .vimrc:
augroup vimrc_autocmd
autocmd!
"toggle quickfix window
autocmd BufReadPost quickfix map <buffer> <leader>qq :cclose<cr>|map <buffer> <c-p> <up>|map <buffer> <c-n> <down>
autocmd FileType unite call s:unite_settings()
" obliterate unite buffers (marks especially).
autocmd BufLeave \[unite\]* if "nofile" ==# &buftype | setlocal bufhidden=wipe | endif
" Jump to the last position when reopening a file
autocmd BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g`\"" | endif
" ...etc...
augroup END
The autocmd! at the beginning of the augroup block clears out the current group (vimrc_autocmd, in this case) before re-adding the autocmds.
From another stack overflow question, I get vim fast by adding the following line in .vimrc file:
set re=1
This will force vim to use a older version of regex engine and it is actually FASTER for ruby.
I found that "set foldmethod=syntax" makes 7.4 almost unusable slow e.g. for js&ruby files (ubuntu 13.10) whereas "set foldmethod=indent" works fine.
I've noticed that vim can slow down to a halt if you're using anything that dynamically changes the background color. Try turning off :set cursorline or :set cursorcolumn (if you have them set).
I'd like to thank everyone helping me out on this issue. Good news is, my Vim is snappy again.
I've started with fresh Vim re-install. I've than added plugin by plugin, until I found the root of all evil.
Bundle "gorodinskiy/vim-coloresque.git"
Its a plugin that was causing me all this pain. Since I had it for a while, it wasn't a suspect, thats why I discovered it so late.
What this plugin does, is whenever it finds a word for color (eg red, green), or hex value (eg. #FFFFFF), it sets background color of the text to match the color that its describing. Brilliant idea, but seems like poor implementation.
Removing this plugin removed the lags.
But I didn't stop here. I've done a major cleanup of my .vimrc as well. Removed some more plugins I hadn't used. Grouped my autocmds and removed unnecessary ones.
My Vim is very snappy now. I'm happy again.
Syntax highlighting can be slow, but that should be limited to some (somewhat pathological) files, and particular syntax(es). The latest Vim 7.4 has a new command :syntime to troubleshoot syntax highlighting slowness.
Apart from that, often, a binary search where you disable half of your plugins, then only one half of that (when the problem is still there), or the other half (when the problem vanished) lets you get to the problematic script quickly.
I'm pretty sure that
set t_Co=256
set background=dark
colorscheme candyman
have nothing to do with that lag. The two first lines are useless (the number of usable colors is defined according to your $TERM and your colorscheme already does set background=dark) but not really harmful.
Common "Vim is slowing to a crawl" causes include poorly written autocmds, too many autocmds, reloading one's ~/.vimrc too often, poorly written plugins…
Please post your setup so that we can help you find out why you experience that lag.
I have had this problem for a long time, and it was driving me crazy. I tried installing vim-ruby. Not sure if that helped but at least now I have the most up-to-date version of ruby syntax highlighting (with any performance improvements since the last version of Vim was released).
But then I looked further, and discovered that vim-ruby has a mode that skips all the expensive highlighting. Try adding this line to your vimrc and see if it helps (it did for me, finally!):
let ruby_no_expensive=1
For me that was set relativenumber feature which was slowing it down. Try to disable it with set norelativenumber and test.
Just in case it helps anyone out there:
I had accidentally created an extremely large tag file for my project; so my syntax highlighter was searching the large file to highlight function names.
So check your tag file! (In my setup I was using easy-tags so mine was placed at ~/.vimtags
Very late, but I figured this may help someone in a similar boat as me.
The plugin vim-nerdtree-syntax-highlight turned out to be lagging my entire editor. They do mention on their Github that people have reported lag issues, and offer some solutions.
So if anyone happens to be using that plugin, try using some of the fixes listed; this one works, but you need to be selective about which languages you want to keep:
let g:NERDTreeSyntaxDisableDefaultExtensions = 1
let g:NERDTreeDisableExactMatchHighlight = 1
let g:NERDTreeDisablePatternMatchHighlight = 1
let g:NERDTreeSyntaxEnabledExtensions = ['c', 'h', 'c++', 'php', 'rb', 'js', 'css']

What line of code I could add to vimrc to make <leader>ig command run when vim starts?

I'm new to Vim, sorry for this newbie question. I'm using a vim plugin vim-indent-guides
The default mapping to toggle the plugin is <leader>ig. What modification should be made to make it toggled on when vim-started
Sounds like something the plugin might support in its configuration.
Vim plugins are generally configured by putting something like
let g:global_variable_for_plugin = 1
in your ~/.vimrc.
Lo and behold, from the vim-indent-guides documentation:
Use this option to control whether the plugin is enabled on Vim startup.
Default: 0. Values: 0 or 1.
>
let g:indent_guides_enable_on_vim_startup = 0
<
What you need is to run the following command at vim startup
:IndentGuidesEnable
One of the ways is to add an autocommand to your .vimrc like
au VimEnter * IndentGuidesEnable
There are probably other ways but this looks pretty simple for me.
I have no idea why that plugin is not enabled by default but the
IndentGuidesEnable
command seems to do just that. Add it somewhere in your ~/.vimrc.
More generally, mappings are just convenient shortcuts for commands or sequences of commands. You want to execute the command, not the mapping.
I know this is question is long ago but just an update. The selected answer doesn't work on Neovim. To fix that, add this in .vimrc:
autocmd VimEnter * :IndentGuidesEnable

Vim response quite slow

If I open a file containing 5,000 lines of code and continue to input, I found that my vim became very slow, it displays my input after about 1s.
It even won't become any better after I start up with --noplugin. But after switching my .vimrc file, everything gets fine again. The .vimrc file is written by myself and after checking for some time, I still can't locate the error. I have clear all the key maps, but the problem still exists.
So can you give my any advise or tell my how to debug in vim? I found there is a debug option but can't get how to work.
You can use the --startuptime option when start vim:
--startuptime {fname} *--startuptime*
During startup write timing messages to the file {fname}.
This can be used to find out where time is spent while loading
your .vimrc, plugins and opening the first file.
When {fname} already exists new messages are appended.
(Only available when compiled with the |+startuptime|
feature).
Take following steps to diagnose the problem:
type vim --startuptime log.txt main.java in bash to start vim
type :tabe log.txt in vim to view the log.
The reason for slowness is often the not set or wrong set ruby_path on compile time of vim (see also discussion on google vim/ruby google group). It is easier to set it in vimrc, because you can change it without recompiling vim. You can set the path through the g:ruby_path variable in your .vimrc file. Don't copy and paste both, use the right one.
If you setup RBENV you have to use this one:
" ruby path if you are using rbenv
let g:ruby_path = system('echo $HOME/.rbenv/shims')
If you setup RVM you have to use this one:
" ruby path if you are using RVM
let g:ruby_path = system('rvm current')
You can also use the vim-rbenv plugin, which sets the path too.
For me the part on loading ruby specific functions in vim got 10 times faster.
If you are using jruby, than the start up slowliness can be even bigger. See examples for fixing it here.
If running vim 7.4,
put this in your .vimrc
set regexpengine=1
vim 7.4 has a new regex engine that appear not to work well in some situations. Previous version vim 7.3 used the old engine ( set regexpengine=1 ).
The "slow response" from syntax highlighting problem affects the vim help files as well ( and .vimrc file too ).
Something like this is usually caused by syntax colouring. Try with :syntax off.
Add these lines to your ~/.vimrc or ~/.config/nvim/init.vim:
set lazyredraw " don't redraw everytime
set synmaxcol=128 " avoid slow rendering for long lines
syntax sync minlines=64 " faster syntax hl
Also if you're using tmux, consider adding this to your ~/.tmux.conf:
set -sg escape-time 10

Resources