Don't load vim-preview on unrelated filetypes #31

barraponto opened this Issue Jan 26, 2013 · 7 comments


None yet

3 participants


vim-preview should only load on the respective filetypes (configurable, maybe). Right now, it seems to be loading all the time.


As far as I know almost every plugin works this way:

  • Some small initial stuff is located in plugin/name.vim
  • Main stuff is located in autoload/name.vim.

plugin/name.vim is loaded when you open Vim. It defines some basic commands. But when you execute them it automatically does lazy loading of autoload/name.vim. So must not be a perfomance issue.

However, could you point me to a plugin where it implemented the way you want? (ftplugin doesn't seem to be work as I expected and seems to be not loaded with pathogen at all).

blueyed commented Mar 2, 2014

ftplugin .. seems to be not loaded with pathogen at all

That shouldn't be the case.

However, the plugin+autoload approach is the common ground.

Maybe you can elaborate on what you had/have in mind?


I profiled vim using --startuptime as suggested in

I noticed vimpreview is one of the worst performance offenders regardless of whether I'm opening MD files.

blueyed commented Mar 3, 2014

Can you provide the profiling information?

I am sometimes profiling Vim, too, but never had seen vim-preview up in the list.


Cool! I haven't known about --startuptime! Let me see..


In my case it takes ~ 11 msec.. And I've figured out what exactly causes the delay. We use shell call uname to detect Mac OS and to set appropriate list of browsers by default:

    if(system("uname") =~ "Darwin")
        let g:PreviewBrowsers    = 'open,safari,firefox,chromium-browser,epiphany,google-chrome,opera'
        let g:PreviewBrowsers    = 'firefox,safari,chromium-browser,epiphany,google-chrome,opera'

@barraponto @blueyed Thanks for the interesting report and the involvement.
I've moved defenition of the defaults to autoload. It addresses the issue and now vim-preview takes only 0.230 msec on vim starup.
I guess I can close the issue. The original issue about unrelated filetypes seems to be irrelevant already.

Thanks guys!

@greyblake greyblake closed this Mar 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment