The gap difference in startup time between dein and vim-plug will be larger with more plugins, in favor of dein.
In addition to startup time, runtime responsiveness will be faster due to merging the runtimepath.
Other advantages of dein:
More hooks to support layers in building/configuring plugins.
Additional complexity for more sophisticated use than minimalist philosophy of vim-plug. The end-user doesn't have to deal with this complexity (e.g. handling cached state and when to re-cache rtp), space-vim handles that.
Disadvantage of dein:
Stock dein update notifications are not as nice, though :message log can be read after it is all done. A couple plugins improve on that:
Plugin 'wsdjeg/dein-ui.vim' uses different logic from dein#update(), doesn't call hooks, and uses SpaceVim API for logging so it isn't 100% separate (very long errors when I tried to use it). The output does look like vim-plug, but isn't worth including to space-vim.
Plugin 'matsui54/ddu-source-dein_update' has requirements other than dein, e.g. 'ddu'. So this can't be bootstrapped to be used on first space-vim usage, must use stock dein#update() first. I plan on putting this plugin in a 'ddu' layer I'm working on, to allow subsequent updates with dein to look nice. The interface is an improvement over vim-plug's, which allow navigation of changes in the plugins.
Possible filename conflict in the plugin rtp merge, which can be mitigated by setting 'merged': v:false on one of the plugins. But this is more for the layer author to handle than the end-user (AFAIK, I don't know if this is silent error).
Other effects of PR:
Removes install scripts to support 'zero-install' philosophy.
Change defaults in init.spacevim.
Fixed mistype of "\<Space>" in init.spacevim.
Better validation/handling of info.vim manifest and .spacevim layer problems.
Some new utility functions in spacevim#util#.
:call dein#update() is used instead of :PlugUpdate. space-vim detection of missing plugins and press of 'y' on 'y/N' prompt calls dein#update() now.
In g:spacevim_plug_home symbolic links are made to replicate vim-plug folder tree, as dein changes the tree structure.
Many changes to layers packages.vim and config.vim to support differences with dein. packages.vim are no longer parsed on launch as the list of plugins is cached by dein, any configuration in packages.vim had to be moved to config.vim.
Versions of dependencies (e.g. node, rust, [TODO: ctags, fzf, rg]) are checked to determine what packages to include without adding to startuptime. e.g. if executable('node') && IsSufficient('node --version') to determine if systemwide install of Node.js should be used or if Node.js as plugin should be used. This info is either cached by dein or cached in ~/.local/state/vim, to minimize startuptime.
WIP problems to resolve before PR is ready for review:
~Refactor symbolic links in g:spacevim_plug_home to index into dein's repos/github.com/<author>/<pluginname>. This is to be user-friendly with backwards compatibility with former vim-plug structure, the symbolic links replicate that structure. At present the links are only made during vim-plug->dein plugin migration, plugins added later are don't have links.~
~Add a vim-plug->dein migration procedure to rename autoload/plug.vim with different extension so it isn't autoloaded anymore.~
Cache in ~/.local/state/vim appears to be re-written when it should just be read. EDIT: maybe fixed long time ago, need to find notes.
~In .spacevim, Plug in UserInit() does get y/N prompt to update plugins, and dein is invoked, but doesn't appear to retrieve plugin. Might be issue in spacevim#vim#plug#Plug(), not sure why dein elects not to download it.~
Add 'matsui54/ddu-source-dein_update' and ddu in bootstrap step and verify visual update works. Otherwise I think many vim-plug users would dislike this migration.
IStartup time improved:
Above benchmark is using 'Vim' not neovim, and using:
The gap difference in startup time between dein and vim-plug will be larger with more plugins, in favor of dein. In addition to startup time, runtime responsiveness will be faster due to merging the runtimepath.
Other advantages of dein:
Disadvantage of dein:
:message
log can be read after it is all done. A couple plugins improve on that:dein#update()
first. I plan on putting this plugin in a 'ddu' layer I'm working on, to allow subsequent updates with dein to look nice. The interface is an improvement over vim-plug's, which allow navigation of changes in the plugins.Other effects of PR:
init.spacevim
."\<Space>"
ininit.spacevim
.info.vim
manifest and.spacevim
layer problems.spacevim#util#
.:call dein#update()
is used instead of:PlugUpdate
. space-vim detection of missing plugins and press of 'y' on 'y/N' prompt calls dein#update() now.packages.vim
andconfig.vim
to support differences with dein.packages.vim
are no longer parsed on launch as the list of plugins is cached by dein, any configuration inpackages.vim
had to be moved toconfig.vim
.if executable('node') && IsSufficient('node --version')
to determine if systemwide install of Node.js should be used or if Node.js as plugin should be used. This info is either cached by dein or cached in~/.local/state/vim
, to minimize startuptime.WIP problems to resolve before PR is ready for review:
g:spacevim_plug_home
to index into dein'srepos/github.com/<author>/<pluginname>
. This is to be user-friendly with backwards compatibility with former vim-plug structure, the symbolic links replicate that structure. At present the links are only made duringvim-plug->dein
plugin migration, plugins added later are don't have links.~vim-plug->dein
migration procedure to renameautoload/plug.vim
with different extension so it isn't autoloaded anymore.~~/.local/state/vim
appears to be re-written when it should just be read. EDIT: maybe fixed long time ago, need to find notes..spacevim
,Plug
inUserInit()
does gety/N
prompt to update plugins, and dein is invoked, but doesn't appear to retrieve plugin. Might be issue inspacevim#vim#plug#Plug()
, not sure why dein elects not to download it.~