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)

2 Answers 2


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
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'
if executable('latex')
        Plug 'lervag/vimtex', {'for': 'tex'}
if executable('ghc')
        Plug 'dag/vim2hs', {'for': 'hs'}
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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.