I have a problem with syntax highlighting in gvim.
i have the following command in my vimrc file:
autocmd BufNewFile,BufRead *.v,*.vs,*.va set syntax=verilog
However if i'm in gvim reading a file - "a.txt" and i also have "b.txt" open on split, when i click on b and then return to a , the syntax highlighting is gone after the click.
someone tried to explain to me that the autocmd not always running.
any ideas
The BufRead option only applies when reading a file into a new buffer, so it makes sense that simply switching between splits won't trigger the auto command. The file has already been read into the buffer; it's not read again unless you close and reopen it.
You want the option BufEnter, as it triggers on entering a buffer. Your new command should then look like:
autocmd BufNewFile,BufRead,BufEnter *.v,*.vs,*.va set syntax=verilog
As a side note, it's probably better to use filetype instead of syntax, as syntax won't affect indentation rules, if there are any. Or even better, use a plugin to get everything set up automagically without needing explicit autocommands in your .vimrc. Just from a quick Google, this plugin pops up a bunch.
I have a very weird problem which did not exist in my environment before but now happened. When editing files, I'm used to doing this way:
gvim . #open current directory browsing
scroll up/down to select file, enter then edit.
ctrl-6 #back to previous directory
However one day I found the step3 was failed, it said "No alternate file".
My .vimrc file only contains:
colorscheme darkblue
set number
set autoindent
set nowrap
set ignorecase
set cursorline
I tried to clean all content in .cshrc but the same.
Can anyone tell me what's wrong with my gvim ?
Thanks in advance.
This looks to be a change in behavior introduced in Vim 7.4. The netrw view is no longer stored as an alternate file. See this discussion.
The Vim maintainers seemed split on what the correct behavior should be, but Bram himself offered up this advice with a mapping:
I do realize that editing the directory of the current file is
something I often do, but I never bothered to set up a mapping for
it. Typing ":e %:h" is not too difficult, but CTRL-O to jump back to
the netrw %directory view was easier.
I now added a mapping:
map ,d :e %:h<CR>
Let's see if I can get used to that.
Another related discussion can be found here.
You are likely using netrw to edit a directory. This is the equivalent of :Explore. Sadly netrw has a bad habit of not maintaining the alternative buffer, #. You maybe able to upgrade netrw or use :Rexplore (:Rex for short) to resume exploring.
Another option is to just use :e with wildcards and tab completion to explore files. Use <c-d> to list out completions as well.
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']
I'm trying to detect Go files in vim. I've set this up normally on other computers but this one is stuck.
:set filetype?
filetype=go
So it knows that it's a go file, but isn't triggering the syntax highlighting.
However,
:set filetype=go
triggers it correctly.
:filetype detect
doesn't work, and reopening the file
:e!
turns syntax highlighting off, even though filetype remains set to "go".
I have
set rtp+=/usr/local/go/misc/vim
filetype plugin indent on
syntax on
in my .vimrc (as the instructions say).
What's going on? I suspect there's some other configuration that's undoing the syntax highlighting, but lack the knowledge of where to find it.
I'm not sure exactly what the problem is… However, you can try :scriptnames to see what files were loaded by Vim.
One step further, you can set verbose=9 in your .vimrc and restart Vim. Careful, this is really verbose, try to tweak that number down.
I have tried the usual approaches, and have read :help tex.vim
(see : http://vimdoc.sourceforge.net/htmldoc/syntax.html )
I've taken a brief look at syntax/tex.vim, but can't see how to disable it without rebuilding vim without folding. I'm sick of hitting 'zE'.
Lines I've tried in my .vimrc:
set foldlevel=manual
set foldlevelstart=99
let g:tex_fold_enabled=0
Just noticed that there are variables to control folding in vim-latex-suite, at least as of v1.6 of the plugin. The functionality is documented here:
http://vim-latex.sourceforge.net/documentation/latex-suite.html#latex-folding
In short you should be able to change three global variables to get rid of all folding:
:let Tex_FoldedSections=""
:let Tex_FoldedEnvironments=""
:let Tex_FoldedMisc=""
That should get rid of all folding. If you want to disable some folding but not all then you can control things by setting the appropriate values for each variable, as described in the documentation link above. Hope that helps.
What about
autocmd Filetype tex setlocal nofoldenable
The folding functionality all seems to located in folding.vim file of latex-suite distribution. This file is referenced in line 825 of my main.vim file in the latex-suite folder of the ftplugin folder. That line reads:
exe 'source '.fnameescape(s:path.'/folding.vim')
Comment out that line and, as far as I can tell, it strips out all the folding in latex-suite plugin. I don't think it affects anything else, but I haven't checked.