ZyX wrote: > On September 12, 2014 1:46:51 PM GMT+03:00, Bram Moolenaar > <[email protected]> wrote: > > > >Nazri Ramliy wrote: > > > >> On Fri, Sep 12, 2014 at 5:04 AM, Bram Moolenaar <[email protected]> > >wrote: > >> > Although removing arbitrary limits is good, making 'runtimepath' > >very > >> > long is a bad idea. Every time Vim searches for a runtime file it > >will > >> > visit those directories and request the contents. > >> > >> Hmmm it seems that ex_cmds2.c:do_in_runtimepath() could benefit from > >a litte > >> memoization, perhaps expiring the cache whenever 'runtimepath' is > >modified. > > > >That will very quickly get complicated. Esp. whenever changing runtime > >files. > > > >> > A plugin manager better use another mechanism. A dictionary to > >lookup > >> > what file is located where is a LOT faster. > >> > >> Sorry for not researching this thoroughly, but isn't all what a > >plugin > >> manager does is populate 'runtimepath' and then leave all the rest to > >> vim? > > > >My startup time has drastically increased on a system where I started > >using a plugin manager. I have asked before how we can make this work > >better, probably by adding some code inside Vim. > > Currently most plugin managers work in "one directory per plugin" > fashion. If they were more like other package managers (especially > almost all system ones) in "one directory per purpose" fashion (merged > plugin trees in $HOME/.vim) it would solve the issue, but this is > harder to code properly.
If it's a plugin script, not depending on a filetype, the plugin manager could put just one file under $VIMRUNTIME/plugin that sources the plugins from wherever they are located. Enabling/disabling a plugin would then be uncommenting/commenting a line in that file. Filetype plugins require a file with the name of the filetype. The plugin manager could add just one directory, where the subdirectories contain one-line files that source the plugin file from where it's actually located. These files would be removed when disabling a plugin. The extra indirection of sourcing another file is much less than the effort Vim must do to search in directories in 'runtimepath'. This way you can use git or something else to update the directory with the plugin, while the plugin manager itself makes the connection between the 'runtimepath' directory. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
