I think noticing a slow redrawing and slow cursor movement on a fastest PC, is one of the popular frustrations with Vim. Here I am as a yet another instance.

I have a fresh installation of VIM, with the $MYVIMRC at the bottom.

My problem is basically a painful slowdown of cursor movements and screen redraws, which are seen often after a while when

  • lot many buffers parallelly open
  • a longer sessions with multiple buffers used but not immediately after I start vim. They may not be the only cases though.

This is frustrating because, the problem is not easily reproducible. I cannot debug by line by line in $VIMRC, because I don't know how long should I wait to see slow down. All that I could do over the time is to observe the two above cases.

Can some of the vim-monks quickly see where the problem is in the vimrc below? (I copied all except a heap of :nnoremap commands that I often use)

:set nocompatible
:set regexpengine=1     "The new engine replaced with old (suggested on vi.SE)
:set foldmethod=marker   "fold based on default-markers 
:set foldnestmax=10      "deepest fold is 10 levels
:set nofoldenable        "dont fold by default
:set noswapfile     "Realized that swap troubles much more than it helps 
:set number
:set wildmenu
:set guifont=Monospace\ 12
:colorscheme industry

"Make search more user-friendly
:set incsearch  "Search as you go
:set hlsearch   "Highlight matches
:set ignorecase "Case-insensitive searches

:set showmatch  "Quickly jump to matching bracket/brace etc

 %for highlighting in red all exceedingly longer lines
:au BufWinEnter * let w:m2=matchadd('ErrorMsg', '\%>85v.\+', -1)
                      "==> This seems to be the potential culprit..

:filetype plugin on
:runtime macros/matchit.vim

:set formatoptions=tcroqlj

:au VimLeave * :mapclear 
:au VimLeave * :mksession! ~/.hari_vim_session
:au VimLeave * :%normal g_lD

set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'VundleVim/Vundle.vim'
Plugin 'tpope/vim-surround'
Plugin 'tpope/vim-repeat'
Plugin 'vim-scripts/tComment'   " Toggle Comments -- comment/uncomment
Plugin 'scrooloose/nerdtree'
Plugin 'vim-airline/vim-airline'        
Plugin 'vim-airline/vim-airline-themes'
Plugin 'bling/vim-bufferline'
                 "Is this bufferline the culprit? Thought it was nice!!
Plugin 'vim-scripts/vis'    "Vertically selection to filters
call vundle#end()

:set lazyredraw   "Don't redraw unnecessarily too many times
:set ttyfast 

BTW, following How do I debug my vimrc file? when I started vim in no-plugin no-vimrc mode, I see no slow down, but the default interface is not usable to me. I need some modifications as I did in above $MYVIMRC. Hope you don't ask me to withdraw the whole $MYVIMRC.

  • Try disabling vim-bufferline plugin. I see some performance issues on it's Github tracker.
    – grodzik
    Dec 16, 2016 at 8:19
  • 2
    Maybe the line highlighting the 85+ columns is the culprit (See this question). Also to expand grodzik comment: maybe a plugin or a combination of plugins causes the slowdown. Try to comment all of your plugins and use Vim for some time, if the slow down stops, reenabled them ones by ones and you'll eventually find which plugin is causing the problem. Edit you use regexpengine=1 I didn't see that, so matchadd should not be a reason of the slow down... I would still try to comment it, just to be sure.
    – statox
    Dec 16, 2016 at 9:01
  • 'nocompatible' affects a lot of of other settings and should be at the top of your vimrc file. See :help 'compatible. That may not help your slowdown, but it may affect the way other settings affect the slowdown.
    – garyjohn
    Dec 16, 2016 at 14:14
  • Also, what do you mean by the comment, "swap troubles more than it helps"? I don't notice any difference in performance when swap files are enabled unless the swap files are on a slow file system such as on a remote file system with a slow network connection. Trouble with your swap files could be indicative of an underlying problem that is contributing to other slowness.
    – garyjohn
    Dec 16, 2016 at 15:10
  • 1
    @statox,grodzik Indeed, matchadd seems to make some significant difference as I open more and more buffers, even under regexpengine=1. But I also have bufferline plugin disabled. Bufferline-disabling didn't show much improvement so I disabled matchadd on top. Dec 17, 2016 at 0:23

1 Answer 1


I have no idea if any of the following will help, but here are a few things you could try.

You have the following autocmd:

:au BufWinEnter * let w:m2=matchadd('ErrorMsg', '\%>85v.\+', -1)

I can't read your whole vimrc file, so maybe you already did it in the missing part, but in case you didn't, you should probably wrap this autocmd (and the other ones) inside an augroup.

augroup long_lines
    au BufWinEnter * let w:m2=matchadd('ErrorMsg', '\%>85v.\+', -1)
augroup END

The line au! makes sure to delete all the autocmds inside the current augroup every time you source your vimrc.

Without this augroup and the au! line, each time you source your vimrc, a new identical autocmd is added, and you should be able to reproduce some slowdown by sourcing your vimrc:


... then repeating this command enough time.
For example, to repeat it 40 times, you could type, in normal mode, 40@:.
@: will reexecute the last Ex command, the number of times you asked (here 40).

See here and here for more info.

Currently, the autocmd adds a new identical match every time a buffer is displayed in a window, which is probably unnecessary.

If you reload your current buffer, by typing :e, you should see that a new identical match has been created. You can see it with the getmatches() function, by typing:

:echo getmatches()
" info about the current matches

:echo len(getmatches())
" number of matches

If you reload your buffer enough times, by typing for example 40@: (to reexecute the last Ex command, which here is :e, fourty times), you should see a big list of identical matches.

From there, if you load one of your usual files, you should probably experience some slowdown.

The previous augroup and the au! command won't protect you from these duplications. You need a second protection on top of the augroup.

For example, you could ask Vim to check whether you already created a match with the exists() function:

if !exists('w:m2')
    " create your match and store its identifier inside the variable `w:m2`

The exclamation mark before exists() is there to invert the test. You don't want to create the match when one already exists. You want to create a match when one does NOT already exist.

So, all in all, you could try this autocmd:

augroup long_lines
    au BufWinEnter * if !exists('w:m2') | let w:m2=matchadd('ErrorMsg', '\%>85v.\+', -1) | endif
augroup END

You don't need to disable the 'compatible' option, because it should be done automatically by Vim if it finds a vimrc. From :h 'cp:

When a |vimrc| or |gvimrc| file is found while Vim is starting up,
this option is switched off, and all options that have not been
modified will be set to the Vim defaults.

It's not linked to your issue, but you don't need to prefix your commands with a colon :, because when Vim sources your vimrc it interprets the lines as Ex commands (and not normal commands).

You don't need to prefix your autocmds with a colon either. Because an autocmd executes Ex commands by default. It doesn't execute normal commands, like dd (you would have to write normal! dd, but normal is still an Ex command).

So, as an example, you could rewrite this part:

:au VimLeave * :mapclear 
:au VimLeave * :mksession! ~/.hari_vim_session
:au VimLeave * :%normal g_lD

Like this:

augroup my_augroup
    au VimLeave * mapclear 
    au VimLeave * mksession! ~/.hari_vim_session
    au VimLeave * %normal g_lD
augroup END

You could also try to avoid writing comments right after an Ex command.
Try to write your comments on their own dedicated lines.
In particular avoid adding a comment right after a mapping.

If Vim is still slow, and you suspect something in your vimrc is the cause, you could write the line finish somewhere in the middle of it. But don't write finish between the lines:

call vundle#begin()


call vundle#end()

Anything after finish won't be executed by Vim. If the problem persists, it means the cause is somewhere before finish, otherwise after.

Then, you repeat the process.
If you know that the cause is in the first half of your vimrc, you move finish in the middle of it (that is after 1/4 of the file), otherwise in the middle of the second half (that is after 3/4 of the file).

So, in the first step, you write finish after half of the file.
In the second step, you write it after 1/4 or 3/4 of the file (depending on the result of the previous step).
In the third step, you write it after 1/8, 3/8, 5/8 or 7/8 of the file.

After each step, you should be able to eliminate half of the remaining lines as possible suspects.

To move your cursor right after the first half of your file, from normal mode, you can type 50%.
To move it after 1/4 of the file, you can type 25%.
After 1/8, 12% or 13%, etc.

  • +1 accepted. Thanks a lot! Wish someone like you taught me all this in the first place. Let me guess. Do you have any tutorials by yourself? Dec 17, 2016 at 6:28
  • @LovesProbability No sorry I don't have any tutorial, but there are good resources out there, in the sidebar on the vim's subreddit, a book from Drew Neil called Practical Vim, a tutorial on github (github.com/mhinz/vim-galore)... Dec 17, 2016 at 12:30
  • @LovesProbability I've edited the answer, because I think the previous autocmd could still cause some slowdown. You should probably check whether an identical match already exists before trying to create a new one. I've tried to explain it in the edited answer. Dec 17, 2016 at 12:32
  • @LovesProbability Basically you should probably replace let w:m2=matchadd('ErrorMsg', '\%>85v.\+', -1) with if !exists('w:m2') | let w:m2=matchadd('ErrorMsg', '\%>85v.\+', -1) | endif. Dec 17, 2016 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.