Just came across this today and thought it was pretty nifty how they made it a simple install and gave instructions for how to add your own local customizations without breaking the upstream source.


This seems mostly to target ruby developers, but I think there is a lot to pick up there.

IIUC, Janus supplies a rakefile so that users can install the recommended vim scripts using rake. We should think of using this, and other approaches, to install various components:

Vim scripts
See #1139034: Vim Plugins?.
Executable files
Certainly Exuberant ctags, probably CodeSniffer perhaps others.
Drupal projects
Such as Coder, Coder Tough Love, Secure Code Review (in development), and Drupal Code Sniffer and their dependencies. See #1328552: Add support for Coder code reviews and Syntastic plugin and the comments there.


See #16 below for instructions on installing with drush. We need feedback on the pros and cons of this approach, since it involves a major change to the directory structure: see #13–#15.


msonnabaum’s picture

I'm actually a janus user myself and it's definitely a worthwhile project.

Since they use rake to install, how about we do a drush installer? Shouldn't be too hard.

skottler’s picture

msonnabum and I spoke about this a bit earlier today and we agree that it would likely be easier to implement this solution through Drush if this project was ported to be a plugin. As a plugin, it would be easier to to manage updates and would prevent from forcing new users to merge their existing .vimrc with the one that the project provides them. Lastly, we could easily provide Drush commands to handle the install.

skottler’s picture

Status: Active » Needs work
benjifisher’s picture

I have not tested it, but I looked at the description of pathogen. I think that our directory structure will work well with pathogen. Just install our files as ~/.vim/bundle/drupal/*. For example, our vimrc/plugin/drupal.vim would be installed as ~/.vim/bundle/drupal/plugin/drupal.vim.

On UNIX-like systems, we can test for whether pathogen is installed either by checking for ~/.vim/bundle/ or by running

$ echo '2verbose runtime autoload/pathogen.vim' | vim -e -s

and analyzing the output (sent to stderr).

kostajh’s picture

This plugin works fine with pathogen. I'm not sure anything else needs to be done, unless we want to prompt people to optionally install snipMate and Drupal Snippets.

benjifisher’s picture

At least we should add something to the installation instructions: if you use pathogen, then install it this way ...

If we want to get fancy and write an install script (drush? Windows? vimball?) then we might try to determine whether pathogen is installed. If so, install under bundles/, maybe as bundles/drupal/; if not, then install directly under the vimfiles directory.

benjifisher’s picture

Priority: Normal » Critical

I am marking this issue as critical, since I think it should be resolved before we release vimrc 1.0.

I have seen the light. In comment #6, I was thinking that we had to choose a type of install script. The right thing to do is supply every type of install script, so that the end user can choose: vim script (like vimball or :GLVS), bash script, rake, drush, ...

I will also update the issue summary.

bserem’s picture

I would like to believe that a bash script wouldn't be to hard to make.

If I get the problem correctly: we want an automated way for the user to donwload all the files from the repository and place them inside ~/.vim (in Linux). Right?

benjifisher’s picture

Issue summary: View changes

I added several components in addition to vim scripts that I think an installer should handle.

skottler’s picture

Assigned: Unassigned » skottler

I will implement this. It will be drush based, as this is the standard in our community.

benjifisher’s picture

@bserem, see what I added to the issue summary. I think we want to give an easy way to install other vim plugins, executables, PHP scripts, and other Drupal projects, not just the files that this project provides.

@skottler, thanks for taking this on. I think that #4 above can help in testing what plugins are already installed. For more details,

:help -e
:help -s-ex

in particular, and :help startup-options in general; and

:help :verbose
:help 'verbose'

and maybe also :help 'verbosefile'. See also the note under :help vimrc about the -s option.

As I said in #7, I think it will be good to have more than one way to install. A bash script will work on Linux and Mac, but not on most Windows setups. (It should work if Git-Bash is installed.) My own bash scripting skills are weak, and I have never written a drush script nor a rakefile.

bserem’s picture

Version: » 7.x-1.x-dev

I do not if something has been implemented in this direction but I'd like to mention that since the project has a release (7.x-1.x-dev) one can easily download it with drush.

Just do:

cd ~
drush dl vimrc
mv vimrc .vim

or for copy/pasters: cd ~ && drush dl vimrc-7.x-1.x-dev && mv vimrc .vim

While this is not technically an installer it will probably help people with trying this project.

benjifisher’s picture

There is more to it than that. If the user already has a vimfiles directory, we do not want to overwrite it. Then there are the recommended plugins, including pathogen. Basically, everything on http://drupal.org/node/1389448 and http://drupal.org/node/1389472 should be automated. See the issue summary (above) for some other suggestions.

benjifisher’s picture

I have been thinking about how to make it so that this project can be easily installed with drush, something like

$ drush @none dl vimrc
$ drush vimrc-install

Part of the problem is how to get drush to recognize that we are defining drush commands.

One solution is to completely rearrange the code. Untested, but something like this:


and put everything currently in the project (except README.txt) under that last directory. Then the installation script would install pathogen (unless it is already there) and configure it to look in the directory vimrc/bundle.

With this structure, drush should recognize the project as defining drush commands and install under /usr/share/drush/commands (if available) or ~/.drush according to http://drush.ws/#pm-download.

Other vim plugins (NERDTree, Syntastic, fugitive, ...) could be installed under path/to/vimrc/bundle/.

This would be the biggest change to the project's organization since #1140306-14: Play nicely with other uses of Vim. Let's not do it without a bit of discussion.

One downside is that installation would be more complicated for anyone *not* using drush nor pathogen. They would have to copy or symlink the files under vimrc/bundle/drupal into their own vimfiles directories (~/.vim on Linux and Mac, $HOME/vimfiles on Windows).

The upside is the convenience for those who do use drush. A minor benefit is that it makes more sense to have a directory named vimrc under ~/.drush than under ~/.vim.

psynaptic’s picture

I have been thinking of creating an installer myself for my own vim bundles. It would be nice to be able to install this without drush, since not all the systems I use have drush available.

benjifisher’s picture

Thanks for the feedback!

If you are using pathogen but not drush, installation would be only a little more complicated. Instead of putting the project under ~/.vim/bundle/ and being done, you would (following the suggestion in #13) save the project in any convenient place and add one line to your vimrc file::call pathogen#infect('.../vimrc/bundle')
The only serious complication would be for those who are using neither drush nor pathogen, and that is already clunky. (Updating without pathogen is even clunkier.)

benjifisher’s picture

Assigned: skottler » benjifisher
Status: Needs work » Needs review

We need a downloadable release in order to test the new installer. So I created a special branch for this feature and made an alpha release.

If all goes well, then this project can be installed with

$ drush @none dl vimrc-7.x-1.0-alpha1
$ cd ~/.drush/vimrc
$ drush help vimrc-install
$ drush vimrc-install

In order for this to work, this release reorganizes the code as suggested in #13 above. The cd ~/.drush/vimrc step is only needed because I was careless about relative paths. The latest git version is already fixed, so we will only need this step for the alpha1 release.

benjifisher’s picture

TODO: Download more plugins (see http://drupal.org/node/1389472) and run :Helptags as part of the installer.

mlncn’s picture

Awesome, Benji!

On trying to install this, is @none supposed to make it work anywhere? Is it a Drush feature or specific to your setup? Do i still need to run Drush from within a working Drupal directory?


benjifisher’s picture

Thanks for taking a look, Ben!

The @none tells drush to ignore the current site information, so that it will not look for a release matching the major Drupal version. I figured this out when trying to download drush_sup (drush site-upgrade) from a D6 site: #1809116: Installation fails if current version of Drupal is 6.x..

It should work from any directory. I think I tested from the home directory of the guest account on my Mac.

What environment were you using to test?

I am still interested in feedback on whether the advantages of easier drush installation outweigh the disadvantages of harder non-drush installation. See #13-15 above.

benjifisher’s picture

Issue summary: View changes

Removed trailing white space.

psynaptic’s picture

I manage my vim bundles with pathogen and git submodules so I don't at the moment see the benefit of the drush command for me personally.

benjifisher’s picture


Is the extra work I described in #15 enough of a problem that you would argue against reorganizing the code?

If you sometimes use drush, then it would be nice to use drush vimrc-tag-gen without having to specify --include=path/to/vimrc/drush. (See #1735030: Drush command to create your own tags file.) Not to mention the other drush commands we have not even thought of yet. (Sorry about the extreme vaporware!) The reorganization that makes drush installation easier will also make any other commands we add available without having to specify the drush include path.

psynaptic’s picture

@benjifisher: I prefer to keep my vim bundles under ~/.vim/bundle as submodules and I have a repo on github so I can quickly install them on other systems. The installer I wanted was one which would facilitate more easily setting up my own environment with all of my vim bundles in one go. I keep my .vimrc in the same repo so it would be something like this:

mv ~/.vim ~/.vim-old
git clone --recursive git@github.com:psynaptic/vim-bundle.git ~/.vim
ln -s ~/.vim/.vimrc ~/.vimrc

This is hardly a chore but I have other stuff I need to install (dotfiles, bash_kit, oh-my-zsh, etc.) too. I have a lot of servers (hundreds) I need to work on and it's a real pain having to set things up manually every time.

benjifisher’s picture


Your vimrc file already has the line call pathogen#infect() If you always use the procedure you described in #22, and keep the vimrc project in ~/.vim/bundle/vim-drupal, then all you have to do is add one line to the vimrc file:call pathogen#infect('$HOME/.vim/bundle/vim-drupal/bundle')

Set it and forget it.

benjifisher’s picture


Does Git handle symlinks well? If so, another option is to put vim-drupal/ (your directiry name for this project) directly under ~/.vim/ and then (untested)$ ln -s ~/.vim/vim-drupal/bundle/vim-plugin-for-drupal ~/.vim/bundle
Then you would not have to change your vimrc file.

As I pointed out several years ago on one of the vim mailing lists, vim is flexible. Pathogen contributes to that design goal. (:help design-flexible).

psynaptic’s picture

Hmm, do I need to use the installer? I like things as they are. I add a submodule to the ~/.vim/bundle/ directory and it automatically gets picked up by pathogen. I don't really want a special case for vim-drupal. I also don't really see the benefit of allowing this project to be downloaded via drush.

benjifisher’s picture


You do not need to use the installer. I am worried that rearranging the code, as required for convenient drush installation, will make it less convenient for those who do *not* use the installer. That is why I asked for your opinion. What I want to know is whether you agree that the change I suggested in #23 (or the one on #24) is a reasonable amount of extra work, or whether you think it will be a continuing annoyance.

For those who use drush, one advantage of the reorganization is that they can invoke the drush commands defined in this project (so far drush vimrc-install and drush vimrc-tag-gen) without specifying an include path. Another advantage is for vim newbies, who do not want to know about vimrc files and vimfiles directories (~/.vimrc and ~/.vim/). I already have one comment (#18) that it will be a Good Thing if such users can install as I described in #16.

psynaptic’s picture

I'm fine with it since I can just add another line to my .vimrc to point at the bundles directory as described in #23.

benjifisher’s picture


Thanks for the feedback! I am glad you agree that this is a reasonable amount of extra work.

I have committed the changes: 8bed501. Since I have moved around the tags files, the patch is too big to be attached here. I have updated both doc/drupal.txt and README.txt to reflect the recommended methods of installation.

Very soon, I will make another alpha release. Once I do, the recommended method of installation will be as in doc/drupal.txt and README.txt:

        $ drush @none dl vimrc
        $ drush help vimrc-install
        $ drush vimrc-install <options>

for now, use git for the first step:

        $ git clone --recursive --branch 7.x-1.x http://git.drupal.org/project/vimrc.git ~/.drush/vimrc
        $ drush help vimrc-install
        $ drush vimrc-install <options>
benjifisher’s picture

Status: Needs review » Fixed

I tested using the guest account on my Mac. I found and fixed one more bug: #1835658: OpenCommand() fails to return "open" using Mac-installed version of vim.. I released 7.x-1.x-alpha4.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Updated to mention experimental version of drush-based installer.