Plugins you should put in your vimrc | Hacker News Reader

Plugins you should put in your vimrc

vimninjas.com

164 pointsvesln95 comments

I recently "declared vim bankruptcy" and rebuilt my vimrc from scratch. I want a full-featured vim, but I want to keep it responsive.

There are many fancy presets out there https://github.com/skwp/dotfiles https://github.com/carlhuda/janus https://github.com/spf13/spf13-vim https://github.com/vgod/vimrc but they freak me out. They turn vim into a singing, dancing, syntax/spell checking, indexing, buffer Whack-a-mole. My philosophy is that vim shouldn't do anything behind your back, but it should do great things if you ask.

  * Jumping to definitions
  * Finding all uses of a symbol in a repo
  * Running things
    + A test
    + Code in a repl
  * Git blame, diff
  * Summarizing methods in open file
  * Navigating my (rails) app

When putting this together, I found Vundle to be the easiest package manager. Just specify any desired vim plugin github repos in your vimrc and let the :BundleInstall, :BundleClean etc commands do the rest.

I used the standard plugins for most of the stated objectives, but there are places where I found some tricks. The coolest trick is running external programs without locking vim. You can send commands and selections to a tmux terminal using Vimux: https://github.com/benmills/vimux After wrangling with running vim under tmux, I discovered that the vimux plugin works in MacVim too when tmux is running alongside.

The thing I run most often is tests. In Rubyland people advise using Guard, which runs tests automatically when test files change. However this goes against my "don't do things behind my back" philosophy. Vim-turbux is more my taste. It extends vimux to run cucumber and rspec tests with the press of a key: https://github.com/jgdavey/vim-turbux

The next area where most megadotfile presets are lacking is finding the uses of code. Finding code definition is pretty well handled by exuberant-ctags and vim-rails, but finding code uses is trickier. The cscope utility does this, but its language support is limited from what I could tell. Another contender is GNU global. Its setup is...interesting: http://simple-and-basic.com/2008/10/using-rtags-ang-gtags-fo... I couldn't get it working and the GTAGS files it generates cluttered my repos. I cheated and just mapped a key to do :Ggrep (git-fugitive) on the current word. While cscope or global would give the finest results, a massive grep comes close. Let me know, anyone, if you've gotten the tagging systems working better.

My work in progress is here: https://github.com/begriffs/dotfiles I'd appreciate any criticism; I have lots to learn.

I prefer CtrlP to CommandT, since it does not requires external programs.

https://github.com/kien/ctrlp.vim

i had trouble with CtrlP initialy because the initial load time is too slow. However, this config line fix it for me

  let g:ctrlp_user_command = ['.git', 'cd %s && git ls-files']

It lets CtrlP use git to list files, which is much faster for large project

I've tweaked mine to this, which includes untracked files, but honours your gitignores:

  let g:ctrlp_user_command = ['.git/', 'cd %s && git ls-files --exclude-standard -co']

It was annoying me that I couldn't open files I'd just created with CtrlP, as they wern't yet tracked.

Just tried this out on my setup, and it made a huge difference. A large project that used to take ~1s to load the first time is now pretty much instantaneous.

A bunch of people have posted about Ctrl-P being slow but I've never had that problem. Here's my user_command:

    let g:ctrlp_user_command = "find %s -type f | egrep -v '/\.(git|hg|svn)|solr|tmp/' | egrep -v '\.(png|exe|jpg|gif|jar|class|swp|swo|log|gitkep|keepme|so|o)$'"

While the CtrlP window is open, hitting F5 will refresh the list of files and it's really fast. I'm on an SSD but it's still basically instant on every project I code in. I think it must have a slow default which gives people the impression that it's slow. After using both FuzzyFinder and Cmd-T for a long time, CtrlP has been easily the best of the bunch.

If you are concerned about speed, it might be worth adding this line to your vimrc as well. This way, ctrlp will keep its cache (stored by directory), and you only need to rebuild it when you create new files.

  "Keep caches between sessions - f5 to refresh
  let g:ctrlp_clear_cache_on_exit = 0

As others have said CtrlP is slower; but not having the Ruby dependency makes it _far_ less of a headache to install on Windows, should you ever find yourself on such a machine.

Installing command-t is fairly easy on windows. Just compile as instructed with latest ruby 1.9 + devkit and replace gvim.exe with the one specified in this page https://wincent.com/comments/6544.

That's a perfect example of something that is both easy AND a headache. It's not certainly difficult to do, but I don't want to be replacing my gvim executable with one provided by an anonymous forum user just to make one script work. Ignoring the potential security issue, what happens when I want to upgrade vim, or run another script that's similarly "easy" to install on Windows?

I can't speak for other vim users, but I haven't had a lot of luck with distro versions of vim and Ruby/Python extension scripts on Linux either. After fighting with it for a while, I ended up just declaring my .vimrc to be a VimScript-only zone. It sucks losing Gundo and Command-T and a couple other great plugins, but it's done wonders for my sanity, and everything works well on Windows as a bonus.

Well the forum is not actually an anonymous forum, the site owner is creator of command-t plugin. When I encountered crash after installing command-t after upgrading to 7.3 almost 1.5 years ago the first google search led me to that page (now first result is this page http://chrislaco.com/blog/gettimg-command-t-working-on-windo..., even better with instruction).

I also had no problem installing it in Ubuntu/Mint. Just removed vanilla vim and installed vim-gtk and then compiled command-t.

Command-t is actually my only non-vimscript plugin in my plugin list, and it is rightfully so :). I tried to cope with CtrlP, but it feels too slow for me for large collection of files. Also its fuzzy matching is not on par with command-t. I have actually no problem to take this little hassle to install command-t for performance consideration :).

Not quite as easy as installing vanilla vim and dropping my ~/.vim (IIRC it's ~\_vim on windows) in place without touching anything.

easy, but not simple

Or OSX where I can never seem to get vim to build from source (which is the only option for Ruby or even Python integration). I know I've done it in the past but every time I need to I forget the magic I need to do.

The vim that ships with 10.8 (and IIRC 10.7, maybe 10.6) has ruby and python linked out of the box, and straight-up

    ./configure --enable-rubyinterp && make

works just fine on my machine.

Or if yours isn't for whatever reason, you could cheat and grab MacVim[0] then symlink `/Applications/MacVim.app/Contents/MacOS/Vim` to `/usr/local/bin/vim` (editing paths as necessary)

[0] https://github.com/b4winckler/macvim

Just use MacVim and the bundled mvim.

Open file in MacVim:

    $ mivm file

Open file in Vim:

    $ mvim -v file

ooh if I've understood correctly `alias vim='mvim -v'` solves my problem, thanks!

I prefer the builtin vim facilities. I use two features already built into vim. (1) "*" and "**" (ugh stars are italics markers in this editor, how do you escape them?) works in tab completion for both :ts & :e and (2) the --file-tags argument to exhuberant ctags. Oh and one more, :ts supports regexes.

    :ts *Something*xml<tab> (or /Something.*xml<tab>)

will do what you expect. As will

    :e **/somewhere/*myfile*.

That said, I'm going to check ctrlp out to see if I'm missing something good. :-)

Agreed. I used to use Command T religiously, but I move machines frequently due to the nature of my work and was spending more time trying to get it and its dependencies working on the variety of machines that I use than I was actually, you know, coding.

Granted, Ctrl-P is much slower than Command-T. Won't deny it. But carefully excluding all .git, virtualenv (for python) and similar folders in my .vimrc, along with making sure I cd into a directory a little closer to my code makes it almost as quick for me. And it just works, which is invaluable in my book.

I use FuzzyFinder instead of CommandT + BufferExplorer.

http://www.vim.org/scripts/script.php?script_id=1984

For the repo I work in, CtrlP takes about 3 seconds to load for the first time; CommandT is instant. CtrlP is nice for smaller projects, though.

I have strange issues with CtrlP, especially files not being found although they would be a clear match.

Are they already open / matched by wildignore?

As ehynds points out, CtrlP won't list files that are already open. You are supposed to access those using the 'quick buffer switch' mode. I've bound that command to my Tab key, so seeing what files are open and switching between them is a snap.

It also renders Buffer Explorer obsolete, if used with buffer search mode.

Any vim plugin post that doesn't contain Vundle is incomplete, in my opinion. How else are you going to manage all these plugins?

https://github.com/gmarik/vundle

This, a hundred times over, after using vim for 4 years full time (e.g. pretty much 8 hours a day, and who knows how long before that intermittently) I finally took setup vundle, it was so worth all of the 600 or so seconds it took to get working.

Ten minutes is overstating it, even. I just downloaded the thing, pasted the other thing into my .vimrc, done.

I had to weed out all the crap that I had accumulated in ~/.vim/ over the years :)

pathogen

Vundle's better.

Not sure why you've been downvoted.

I agree with your vundle suggestion. I migrated from pathogen to vundle and would recommend that people using the former check out vundle again. Even if it's from the 'wrong author' (aka not from tpope).

The only difference I'm aware of (I haven't looked into it much) is that Vundle downloads plugins too, rather than just install them, but it's a pretty big difference when you're looking for a plugin manager.

It's huge because it lets me manage my plugins in source control much more easily than juggling submodules in git or whatnot. Instead I just have my plugins as lines in my vimrc.

> Not sure why you've been downvoted.

Just stating "X is better" without giving any reason is not particularly helpful.

Agreed, but he replied to a single word comment (=> worse)

but this single word was a very valid reply to the parents question. without needing any explanation.

pathogen requires you to roll your own submodule thingy. This is certainly feasible if you know git well, but vundle is still easier

Not sure where you got that idea: I use pathogen without involving Git at all.

OK, then you have some kind of shell script to do the downloads, or you do them all manually each time. These are not better alternatives

My ~/.vim is under version control (Git) but not every plugin is available through Git. Some plugin developers use Mercurial, others use Subversion or whatever and most only provide a .tar, a .zip, a vimball or even a single vim script. This Git myopia is seriously getting on my nerve.

it does when you want to have your vim configuration in git. and vundle might be easier then (not, that using git submodules is so extremly hard).

Yeah, all I need is a vimrc when I have vundle. I sync it using Dropbox and run BundleInstall on any of my new computers and I'm good to go with all the plugins.

Does Vundle allow you to just unzip plugins that aren't hosted anywhere into their own subdirectory somewhere inside your ~/.vim/ like Pathogen does?

This isn't clear from it's webpage.

I'd like to know this too.

As far as I know, it does. However, I'm not sure.

Every time an article like this comes up, snipMate seems to be mentioned. This particular author even pointed to the old repository which appears unmaintained and has not had a check-in for two years.

Where's the love for UltiSnips? [1]

UltiSnips is actively maintained and well documented, not to mention supporting many more features, such as Python interpolation. More info at [2].

[1] https://github.com/SirVer/ultisnips

[2] http://fueledbylemons.com/blog/2011/07/27/why-ultisnips/

Actually, where's the love for neocomplcache? [1]

neocomplcache is actively maintained and well documented, not to mention supporting many more features, such as file path completion, register completion, omni completion and Vim completion.

[1] https://github.com/Shougo/neocomplcache

Just switched to neocomplcache from AutoComplPop. Enjoying it very much so far.

While the original author has abandoned snipmate, there is a fork that is actively maintained: https://github.com/garbas/vim-snipmate

I've been a happy user of snipmate, but I'll give ultisnips a try. Thanks for the tip!

I do OK with macros which use registers: http://stackoverflow.com/questions/8120486/how-to-provide-pa...

+1 for ultisnips, definitely the superior option when it comes to templating.

I just installed it. It's pretty good. The docs aren't great though. I hate sitting through screencasts.

Can you elaborate?

Because UltiSnips was buggy as hell when I tried.

Because the old SnipMate still works very well. Thanks.

My favorites:

  * pathogen [1]
  * PreciseJump [2]
  * MRU [3]
  * scratch [4]
  * xptemplate [5]
  * renumber [6]

[1] - http://www.vim.org/scripts/script.php?script_id=2332

[2] - http://www.vim.org/scripts/script.php?script_id=3437

[3] - http://www.vim.org/scripts/script.php?script_id=521

[4] - http://www.vim.org/script.php?script_id=389

[5] - http://www.vim.org/scripts/script.php?script_id=2611

[6] - http://www.vim.org/scripts/script.php?script_id=189

Use vundle instead of pathogen - it installs the plugins for you, so managing them in source control is much easier. Lines in a vimrc are much less of a headache than git submodules etc.

> Lines in a vimrc are much less of a headache than git submodules etc.

I disagree. This may be true if you don't understand git submodules, but git submodules are not hard to understand with just a little effort. Once understood, git submodules are very easy to work with.

Also, this may be just a personal quirk, but I'm not very fond of managing vim from within vim. It would bug the living daylights out of me to load vim just to update my plugins. I'm probably the only one who feels that way, though.

Have to agree with the author about his picks. Excluding a couple programming-language specific plugins the only other ones that i'd include on a longer list would be:

EasyGrep - A nice quick way to search for arbitrary text when ctags/cscope doesn't have the answer. https://github.com/vim-scripts/EasyGrep

QuickFixSigns - Show marks associated with each line in a buffer. Also shows lines that have been changed from what has been committed to Git. https://github.com/vim-scripts/quickfixsigns

Would be interested to know what others have to say about SuperTab since i'm thinking of giving it a try. https://github.com/ervandew/supertab

Definitely give supertab a shot. It's recently become one of my favourite plugins and now I'm tabbing religiously

I clicked the article thinking "Please, don't say Surround, Cmd-T, snipmate or Buffer Explorer".. These are amongst the most popular plugins for Vim and every week there are blogs saying exactly the same thing.

Note: I have nothing against this blog in particular.. but please, upvoters, try to upvote new stuff.

I agree.

But, I must say: no matter how repetitive these articles, I pick up something new in the HN comments every single time.

Emacs versions to check out:

Surround: wrap-region (https://github.com/rejeep/wrap-region)

Command-T: ido-mode with ido-find-file

snipMate: YASnippet

Syntastic: flymake

Buffer Explorer: ibuffer

I actually tried really hard to get ido-mode to recursively search files under the current directory, but I was never successful.

Is there some really easy modification I have overlooked? Because that is one of the major advantages CtrlP or Command-T have - and trying to use https://github.com/emacs-helm/helm with https://github.com/bbatsov/projectile turned out to be by far too slow.

I've moved to ctrlp over Command-T as it's pure Vimscript. Feels even faster than Command-T to me:

https://github.com/kien/ctrlp.vim

How many files is the project you try it on? CommandT is faster for me, but only noticeably on large projects.

Before snipMate came in 2009, snippetsEmu was already out there, since 2005! It's true though, that snipMate may seem more robust.

Check also pkrumins' Vim Plugins You Should Know About:

http://www.catonmat.net/blog/vim-plugins-surround-vim/ http://www.catonmat.net/blog/vim-plugins-repeat-vim/ http://www.catonmat.net/blog/vim-plugins-matchit-vim/ http://www.catonmat.net/blog/vim-plugins-snipmate-vim/ http://www.catonmat.net/blog/vim-plugins-a-vim/ http://www.catonmat.net/blog/vim-plugins-nerdtree-vim/ http://www.catonmat.net/blog/vim-plugins-ragtag-allml-vim/

One of my favorite plugins that hasn't been mentioned so far is vim-powerline https://github.com/Lokaltog/vim-powerline. It makes Vim have a really polished look to it, and more important: tells you which Git branch you're currently in.

For me, vim-powerline gives a much stronger visual indicator of the current mode. Changing the color of the whole statusline really stands out.

Wow, another post with the exact same plugins as all the other posts.

These are all the 13 plugins currently sitting in my bundle directory:

* AutoComplPop

Provides auto completion. I like/need auto completion less and less, these days, so this one is on its way out. I tend to deactivate it and use my old custom mappings for omni completion instead.

The no plugin way:

    inoremap ,, <C-x><C-o>

* Commentary

Toggles comments.

The no plugin way:

    0i//
    :s+^//++

* CtrlP

Super sleek fuzzy file/buffer/tag navigation. I love it.

The no plugin way:

    :e filename
    :sp *na<tab>
    :vs **/fi<tab>
    :sb *na<tab>
    nnoremap <leader>ls :ls<CR>:sb<Space>
    etc.

* DelimitMate

Automatically adds the second "')]}.

The no plugin way:

    inoremap { {}<left>

* EasyGrep

Handy cross-files/buffers search/replace. More convenient than the default mechanism.

The no plugin way:

    :vimgrep <cword> *.js | copen

* InsertImg (customized)

Inserts an <img> tag with the correct width and height.

* SnipMate

I use the old one as it does everything I need without any problem.

The no plugin way:

    :help abbreviations

* Sparkup

Uses CSS syntax to quickly create large HTML layouts:

    div.aclass*5 > p{lorem ipsum} + img.anotherclass[src=/images/img.png]

* Surround

See the article. This one is almost a good reason in of itself to switch to Vim.

* Syntastic

Syntax checking of many languages on the fly. Super handy.

* Tabular

Because I like my code neatly aligned.

* Visincr

I actually don't use this one much but it helps a lot when I need to write lists of numbers/letters.

* Word-Column

The new kid on the block. Provides a text-object for columns.

and the 14th, currently testing:

* EasyMotion

Thank you for showing how to use the plugins, most of these articles don't.

I looked at the rest of the site, bookmarked!

Can I make an article suggestion though? I'm a new(ish) vim user that is always on different systems. I need a way to quickly install/remove my vim settings and plugins. A tutorial how to do this would be awesome.

Take for granted vim and git are already installed, my ideal workflow would be something like this:

git clone git://blah.blah/my_settings.git ./my_settings/install.sh

Now I can run vim and my whole environment will be ready. If I make any changes I should be able to run git push to update the repository. Then I could run remove.sh to clean everything up.

Is there a system like this out there already?

As I posted above, there's Vundle:

https://github.com/gmarik/vundle

You just copy your .vimrc over and Vundle installs everything.

Vundle seems like it only takes care of the plugins. I'm looking for a vim install system, like Python's setup.py.

The rage these days seems to be to keep your own dotfiles repo, complete with some kind of install mechanism.

My own is here [1] but it covers my whole homedir, not just VIM. I use Rake tasks (originally inspired by @holman, I believe) for install / update / clean.

There is a bootstrapping problem when using Vundle with many plugins [2]. The only way to have your Vundles install cleanly the first time is to split up .vimrc into two separate files, which is what I have done.

[1] https://github.com/anthonywilson/dotfiles

[2] http://www.gmarik.info/blog/2011/05/17/chicken-or-egg-dilemm...

Can you elaborate on your requirements/wishes here?

For me my vim environment consists of my vimrc plus plugins. Granted, I pick plugins based on the "doesn't need extra steps to work" requirement.

vundle therefor restores my setup completely from a (potentially restored or managed in a git repository) vimrc file. What's missing for you?

Thoughtbot dotfiles (https://github.com/thoughtbot/dotfiles) works something like that. I've branched it for myself and extended it.

https://github.com/davidbeckingsale/writegood.vim

The Writegood scripts can be handy if you write non-fiction prose in Vim.

A strange synchronicity: I came across the page at

http://matt.might.net/articles/shell-scripts-for-passive-voi...

and duly copy/pasted the bash scripts and ran them over some text files. Quite useful. Then I saw this thread and wondered if anyone had done a vim plug in for them. And davidbeckingsale has.

I already happen to have these in my setup; if you're a git user I highly recommend fugitive.vim too.

https://github.com/tpope/vim-fugitive

I tried to incorporate it in my workflow several times, but usually I end up <C-Z>ing the Vim process and commit, branch etc. via the command line. I understand that Fugitive _might_ help resolving merge conflicts, but this is really just a small percentage of my daily Git workflow.

Maybe, there is some deeper sense in it that I haven't grasped yet?

That's what I do, too. I keep it around for :Gblame.

try this:

:Gdiff

OTF isn't mentioned often but is extremely useful if you have to work with log files on a regular basis.

It allows you to define up to 10 search terms and highlights them in different colors, making it easy to see patterns of output in logs.

It doesn't sound that amazing at first but is worth trying if you herd log files for a living.

http://vim.sourceforge.net/scripts/script.php?script_id=634

Among the things I personally couldn't do without these days snipMate, which is mentioned in the article. Then there's clang_complete which made me very happy. Finally a compiler-based auto-completion for C in vim. Last but not least there's fugitive. That's really most of what I need since vim already provides a lot of useful features by itself.

I agree to these five, and add:

* matchit - extends % functionality to support HTML/XML tags and also functions, blocks, conditionals in many languages.

* Supertab - tab completion done right.

* Tagbar or Taglist - code tree browser.

Nice to see another VIM article on Hacker News.

Very useful, thanks. These days I changed double quotes to single so many times and this comes just in the right moment!

installing snipmate through pathogen is still a dark art

1. Download

2. Unzip in ~/.vim/bundle

3. Done

How is that "dark art"?

This is perfect since I'm just starting with vim.

In my experience, it's better to spend a long time playing with Vim, and then look at plugins. There's a lot that Vim does out of the box without any additional tools, and spending time learning to use (some) of it without trying to make it more like another editor is the only way you're going to get better at it. Learn about buffers and how to manage them before using BufExplorer. Learn the (many) movement keys, and insertion, append, replace, substitue, change, options before you use Surround.

It may sound odd, but learn to use the tool by itself before you try and plugin anything else, otherwise you'll just get lost.

I disagree. As someone who started using Vim recently, the issue wasn't learning modes/key sequences as it was just reaching feature parity with my previous editor (note that doesn't mean "acts like my previous editor", just "is at least as capable as my previous editor"). If I can't open files really quickly, I feel lost and upset, so I took care of that very early in the learning process by setting up CtrlP. Same with some other plugins.

More generally, to me, the features that happen ship with Vim aren't special. I want the best editor for me, which might require features the builders of Vim didn't want to include. Vanilla is just another flavor.

That's why you need to learn Vim without plugins. Vim can "open files really quickly":

    :e *ba<Tab>
    :vs ../**/fo<Tab>

I love CtrlP but you can go a long way without any plugins. It just takes some time and effort.

Why are you using Vim and not your previous editor?

I'd say that it's better to start off with installing vundle (https://github.com/gmarik/vundle/) and then whenever you feel like you're having problems doing something like file/buffer navigation, auto-completion or making vim pretty then go out looking specifically for something you like and vunlde will make it really easy to install just by pointing at the github.

Whatever you do, don't install syntastic unless you want your vim to run awfully slow.

So.. we like Vim now?

Reply on news.ycombinator.com