Add dein support
Hi @hyiltiz,
This is a very useful tool. I use it a lot, since I have lots of plugins :(
Lately I wanted to try dein.vim. However, I could not profile it using your tool. I was wondering if you can support dein.vim too? The problem is dein.vim caches its files very differently from other plugin managers.
Thanks.
Hi, I haven't heard it before. I currently don't have time to port it. It is a very simple script though. I can check it out once I get some leisure time. Please contact me after a while if you still works like me to work on it.
On Fri, Apr 22, 2016, 04:18 Khalid H. Ahmed [email protected] wrote:
Hi @hyiltiz https://github.com/hyiltiz,
This is a very useful tool. I use it a lot, since I have lots of plugins :(
Lately I wanted to try dein.vim https://github.com/Shougo/dein.vim. However, I could not profile it using your tool. I was wondering if you support dein.vim too? The problem is dein.vim caches its files very differently from other plugin managers.
Thanks.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/hyiltiz/vim-plugins-profile/issues/9
Sent from Gmail Mobile.
As I understand it, dein.vim is a manager for neovim. I am under the impression that neovim has a very different plugin system. I am not sure how the script will work out. Presumably, it is possible as long as we can get an output similar to vim --startuptime. I haven't used neovim. Would you like to post a profile output from neovim? I am glad to see if I can parse the output for a similar result.
Actually, neovim and vim have the same plugin system. Most people use the same vimrc for both of them :)
The real problem is how dein (the plugin manager), manages plugins. It seems to cache them such that, there is no need to populate run-time path on each startup.
Here is the profile you asked for:
nvim_profile_with_dein.txt nvim_profile_with_vim-plug.txt
And I know, I have lots of plugins :)
Thank you so much for sharing the files. From what I can see from the files you sent me, it seems that dein.vim uses $VIMCONFIG/dein/.dein/format while vim-plug uses $VIMCONFIG/plugged/. The profile output seems the same (as it should be regardless of what plugin manager you are using), so it should be possible to parse. Can you tell me more about what you meant by "caching" that dein.vim uses?
Can you please tell me the output of the following two lines (BASH)
echo $HOME
vim -c ':exec ":silent !echo ".&rtp | exec ":q!"' # might be nvim
dein copies the files to a folder named ".dein" (or any name you choose). And in that directory it creates the autoload, plugin, and other directories, which vim wants. However, in case of vim-plug and other plugin managers, they don't have such a folder with all files from different sources merged. Instead of this, they know which plugins are added and perform runtime path population during startup.
Consider these two:
In case of vim-plug, note how vimproc and vinegar are located in their corresponding directories namely, vimproc.vim and vim-vinegar.
With vim-plug
3224.315 000.200 000.200: sourcing /Volumes/Home/.config/nvim/plugged/vimproc.vim/plugin/vimproc.vim 3745.005 000.612 000.612: sourcing /Volumes/Home/.config/nvim/plugged/vim-vinegar/plugin/vinegar.vim
However, in case of dein, vimproc and vinegar with other plugins are located in the same directory (Path).
With dein
1438.170 000.177 000.177: sourcing /Volumes/Home/.config/nvim/dein/.dein/plugin/vimproc.vim 1454.691 000.565 000.565: sourcing /Volumes/Home/.config/nvim/dein/.dein/plugin/vinegar.vim
Oh, now I see your point. I was looking at the following block:
nvim_profile_with_vim-plug.txt
139:3972.174 000.209 000.209: sourcing /Volumes/Home/.config/nvim/plugged/lightline.vim/plugin/lightline.vim
166:4162.378 001.062 001.062: sourcing /Volumes/Home/.config/nvim/plugged/lightline.vim/autoload/lightline.vim
167:4172.591 000.139 000.139: sourcing /Volumes/Home/.config/nvim/plugged/lightline.vim/autoload/lightline/tab.vim
168:4193.151 000.886 000.886: sourcing /Volumes/Home/.config/nvim/plugged/lightline.vim/autoload/lightline/colorscheme.vim
169:4194.191 004.043 003.157: sourcing /Volumes/Home/.config/nvim/plugged/lightline.vim/autoload/lightline/colorscheme/wombat.vim
nvim_profile_with_dein.txt
78:1088.916 000.257 000.257: sourcing /Volumes/Home/.config/nvim/dein/.dein/plugin/lightline.vim
144:1676.749 001.827 001.827: sourcing /Volumes/Home/.config/nvim/dein/.dein/autoload/lightline.vim
147:1731.434 000.362 000.362: sourcing /Volumes/Home/.config/nvim/dein/.dein/autoload/lightline/tab.vim
148:1734.894 000.711 000.711: sourcing /Volumes/Home/.config/nvim/dein/.dein/autoload/lightline/colorscheme.vim
149:1736.821 003.606 002.895: sourcing /Volumes/Home/.config/nvim/dein/.dein/autoload/lightline/colorscheme/wombat.vim
So, dein.vim expands everything which is quite similar to how you would install plugins traditionally into vanilla vim without a help of plugin managers. While it could be somewhat possible to still group files into their corresponding plugin names based on the filenames in dein.vim's case, some files does tend to have the same name (see colorscheme.vim above). Even so, dein.vim seems to have put files that could have different file names under corresponding directories.
@Shougo, I would love to provide support for dein.vim as well (NeoBundle is already supported). Could you help us point out ways to find out all the files that belong to a given vim plugin that is installed through dein.vim based on the output of vim --startuptime, please?
Yeah, I know that some plugins tend to use the same name. I think I have already seen an issue on dein's github page for that. However, it's very rare :) I could be wrong, but in the issue I mentioned there was only one conflict reported. Sorry, I don't remember the issue title, else I would have pointed you to it.
The cached folder is where cached files are saved. However, there is also another directory named "repos", where all plugin's repos are stored (it's just like vim-plug's plugged directory). Somehow the two can be used together to detect which file belongs where.
Here is the directory structure for dein generated, using tree -L 4 ./:
Update: You already know about .dein directory which is just like traditional vim folder.
@Shougo, I would love to provide support for dein.vim as well (NeoBundle is already supported). Could you help us point out ways to find out all the files that belong to a given vim plugin that is installed through dein.vim based on the output of vim --startuptime, please?
Hm. This is for merged plugins?
You can get the plugin files by glob(dein#get('name').path . '/*').
You must check the files under dein#util#_get_runtime_path() directory.
Opps missed this one :)
echo $HOME vim -c ':exec ":silent !echo ".&rtp | exec ":q!"' # might be nvim
The following is the &rtp output:
/Volumes/Home/.config/nvim/dein/.dein,/Volumes/Home/.config/nvim/dein/repos/github.com/Shougo/dein.vim,/Volumes/Home/.config/nvim,/etc/xdg/nvim,/Volumes/Home/.local/share/nvim/site,/usr/local/share/nvim/site,/usr/share/nvim/site,/usr/local/Cellar/neovim/HEAD/share/nvim/runtime,/usr/share/nvim/site/after,/usr/local/share/nvim/site/after,/Volumes/Home/.local/share/nvim/site/after,/etc/xdg/nvim/after,/Volumes/Home/.config/nvim/after,/Volumes/Home/.config/nvim/dein/.dein/after,/usr/local/Cellar/fzf/HEAD
I deleted this bit from the above output, as it makes things confusing. It may be a leftover from vim-plug or a local repo (not sure):
/Volumes/Home/.config/nvim/plugged/foldsearches.vim,
I use Dein with Vim, not NeoVim. I was able to get it working by grepping .cache instead of plugDir, where Dein merges the plugins. After that, I called basename() on the PlugName before I aggregated them.
@frenchja Are contents under .cache only are only consistent of plugins activated at that time? If you could incorporate the two calls @dein suggested above and make it working, I'm glad to merge it in.
Any progress on this?
I'm willing to merge any pull request to support this. If someone can share a typical vim config that relies on dein, I'd be able to test myself and maybe implement what @frenchja suggested.