Selectively enable a subset of vim plugins for specific category of workflows (plugin virtualenv for vim projects)

Question

I use vim for many different categories of projects, typically:

1. Writing code (3 languages, python, Matlab and C)
2. Writing documentation ( .rst, .html)
3. Writing reports (.tex)
4. Readme file (.md)
5. As a plain text scratchpad (quick notes, meeting minutes etc.)

While I understand why many experts here recommend against relying solely on plugins and instead encourage to leverage vim's power for many tasks, a plugin-based workflow suits my style (and there exist many plugins which simplify the task at hand greatly).

My question is: Can we enable a specific subset of plugins for specific projects (akin to a python virtualenv setup). Some plugins are very generic (eg. an auto-close plugin for {},(),<> pairs) and is helpful in all kind of projects. However, others are more project-specific (eg. vim-jedi plugin would be useless when writing regular prose; any writing plugin will be useless for code and such). I think there is a way selectively enable on-demand/lazy loading for individual plugins. But my question goes beyond this basic case, since it is inconvenient to manually enable a handful plugins (say 3 or 4) one by one as required by a project.

Instead, is there a way to define "plugin-groups" (say, we call them 'writer-tools', or 'matlab-plugins') so that only the plugins belonging to that group are auto-loaded depending on the specific project type/category. Furthermore, it is also desirable to have a manual override feature to either enable individual plugins from other plugin-groups or disable any one plugin from the currently loaded plugin-group, while in the midst of vim workflow.

Does such a meta-plugin to manage group-based plugin autoload feature already exist? (or maybe someone has put together a solution using a bunch of autocmds in their vimrc)

Answer 1

The plugin manager vim-plug supports this to some extent using a for attribute for plugins. For example, here's part of my vimrc:

call plug#begin()
" Common plugins
Plug 'vim-scripts/diffchar.vim'
Plug 'scrooloose/nerdtree'
Plug 'ervandew/supertab'
Plug 'scrooloose/syntastic'
"...
Plug 'ctrlpvim/ctrlp.vim'
Plug 'gabrielelana/vim-markdown', {'for': 'markdown'}
Plug 'majutsushi/tagbar', {'for': ['cpp', 'c', 'go', 'sh', 'javascript']}
Plug 'godlygeek/tabular'

if executable('cmake')
        " YCM command lifted from vim-plug readme
        Plug 'Valloric/YouCompleteMe', { 'do': YCMInstallCmd(), 'for': ['cpp', 'c', 'sh', 'javascript', 'vim', 'tex'] }
        autocmd! User YouCompleteMe if !has('vim_starting') | call youcompleteme#Enable() | endif
endif
if executable('go')
        Plug 'fatih/vim-go', {'for': 'go'}
        Plug 'Shougo/neocomplete.vim', {'for': 'go'}
        Plug 'Shougo/vimproc.vim', {'do': 'make'}
        Plug 'Shougo/echodoc.vim'
endif
if executable('latex')
        Plug 'lervag/vimtex', {'for': 'tex'}
endif
if executable('ghc')
        Plug 'dag/vim2hs', {'for': 'hs'}
endif
"...
call plug#end()

So I have a bunch of plugins loaded for everything, and then the 800lb YouCompleteMe which is only loaded for specific file types, and so on. I think vim-plug only supports filetypes with for, however, so you can't do anything really complex like virtualenvs.

Answer 2

The exact same question had been asked recently on reddit. I copy-paste here my answer. I also recommend you read @romainl's answer.

If the plugins you're using are correctly designed, you should not need to do anything specific.

Since Vim 6 (yeah, 2 versions ago), we have ftplugins, for filetype-plugins. The idea is to load the C ftplugins on the fly when you're editing C files, go ftplugins when you're editing go files, and so on. Even better, we can work on C files and on go files simultaneously without improper interferences.

May be you don't want to load a generic (non-ft) plugin in some contexts. But once again, if the plugin is correctly designed (i.e. made of autoload plugins (that appeared in Vim 7)) starting times should not be a problem.

IMO, we don't need on-demand plugin loading based on filetype. Vim has been supporting this natively since 2001. Of course, ftplugins could be incorrectly written, this is another issue.