Parallel vim installations

Question

I take part in some programming projects. I use vim to code for these projects. For each project I need a corresponding .vimrc with appropriate plugins set and customization. I can use custom .vimrc with command line options -u:

$ vim -u /home/loom/.vimrc.custom

However, I share ~/.vim/ directory for all projects and each plugin I installed for some project is loaded for any vim start. Definitely, I don't want such behavior. So, is there a way to select preferable .vim directory like I can select .vimrc (or maybe to have several vim installation with corresponding .vim)?

Answer 1

I read two problems expressed in your question.

1. depending on the project you could activate different plugins
2. depending on the project you could tune differently, different things.

1- Being picky about plugins loaded

First, I have a question for you. What makes two projects that different that they would require totally different set of plugins?

I suspect, the filetype of the files you're manipulating is what discriminates your projects. I understand you may need different settings for a python project from a C++ project for instance.

Lately, we've seen more and more people advocate a couple of plugin managers able to load different plugins depending on the filetype of the file edited -- vim-plug belongs to that category, there are a few others. IMO, this is a poor man's/pointless solution. First because we could edit files from different projects, or of different types within a same vim session, and because plugins are difficult, is not impossible, to unload. Once, loaded, the plugin is still loaded. If it doesn't play well when files of different types are loaded, then it's badly written. This is sad because we are able to define specialized filetype-plugins since Vim 6 (which is something like 15 years old).

Of course we could think about other situations like: what's the point of loading fugitive with a svn based project? What's the problem with it? Honestly. Yes, not all plugins are exploiting autoload plugins and might slow down starting times. Is this that terrible? Can't we ask their maintainers to improve these plugins?

The only real issue is related to conflicting behaviours and mappings. If it was your problem, I guess you would have made it explicit in your question, wouldn't you?

IMO, this is the only case that might justify such plugin managers, on the condition that you have an extremely strict workflow where you never edit files of different natures. However, ff you start mixing files and if the plugins you're using are poorly made, these plugins managers won't be able to help you in any way.

I'll be back on the subject of loading plugins depending on project (not filetypes) later.

Note that loading plugins depending on the filetype of the files edited is addressed in this question: Selectively enable a subset of vim plugins for specific category of workflows (plugin virtualenv for vim projects)

BTW, Vim 8 packages could be used to define contexts, and thus to load different things packaged together more easily. At this time there are commands to do it on demand, I don't doubt it could be done automatically based on filetypes, or on projects/directories (see below). But again, this doesn't answer the case where files from different projects are loaded within the same vim instance as it doesn't provide any mean to unload/undefine.

2. Project based settings.

This is a subject on which I've spent time. I've developed two plugins that address the issue of tuning stuff based on projects. This topic would be a duplicate of other questions on SO, and on vi.SE.

Let's say I have:

• a plugin library where I've introduced project based variables (as we have b:uffer_variables) and simplified ways to detect projects depending on .git and .svn directories) -- these improvements are almost pointless if the plugins you're using don't depend on p:variable from my library-plugin.
• a plugin that permits to define local .vimrc (which scales unlike modelines, .exrc, autocommands...). It can be combined with my library-plugin for more complex settings. It's really handy to set b:variables, and even g:variables (and also vim options, mappings, commands...) depending on the current project. However, I've never ever considered if it could be used to load plugins at the last moment. First because the only thing I expect of a plugin manager is to support dependencies when installing plugins, then because this is not a need that I share (and yet I could edit, vim, C++, python, LaTeX, markdown... files from a same vim instance, and even files from different projects that are compiled differently).

Answer 2

So, I decided to have original ~/.vim/ directory empty and to create special .vimrc.XXX and .vim.XXX/ for each project. For example

/home/loom/
    ├── .vims/
    │   ├── .vim.foo/
    │   └── .vim.bar/
    ├── .vimrc.foo
    └── .vimrc.bar

First lines of original .vimrc looks like

set nocompatible
filetype off

set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'VundleVim/Vundle.vim'

For original ~/.vimrc :echo &rtp returns /home/loom/.vim,/usr/share/vim/vimfiles,/usr/share/vim/vim80,/usr/share/vim/vimfiles/after,/home/loom/.vim/after

So, I need to redefine rtp. The following is the first lines of new ~/.vimrc.foo

set nocompatible
filetype off

let MYVIMDIR='/home/loom/.vims/.vim.foo'
let &rtp=expand(MYVIMDIR).','.expand($VIM).'/vimfiles,'.expand($VIMRUNTIME).','.expand($VIM).'/vimfiles/after'.expand(MYVIMDIR).'/after'

let &rtp .= ','.expand(MYVIMDIR).'/bundle/Vundle.vim'
call vundle#begin(expand(MYVIMDIR).'/bundle')
Plugin 'VundleVim/Vundle.vim'

Other lines was left unchanged, except possible minor paths fixes