Closed barraponto closed 10 years ago
As far as I know almost every plugin works this way:
plugin/name.vim
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).
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.
@barraponto Maybe you can elaborate on what you had/have in mind?
I profiled vim using --startuptime
as suggested in http://usevim.com/2012/04/18/startuptime/
I noticed vimpreview is one of the worst performance offenders regardless of whether I'm opening MD files.
@barraponto 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'
else
let g:PreviewBrowsers = 'firefox,safari,chromium-browser,epiphany,google-chrome,opera'
endif
@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!
vim-preview should only load on the respective filetypes (configurable, maybe). Right now, it seems to be loading all the time.