I switched to Vim 6 years ago because I wanted to keep my dev setup as lean as possible. I was tired of working in heavy IDEs and wanted a light and fast environment without all the bells and whistles.
Originally, I avoided any plugins that fundamentally changed the editor. If it wasn’t a < ~5 line function I could code myself or crib from Vim’s help command, it wasn’t going in my vimrc.
The Problem:
As the codebase I was working on at the time grew, I started feeling the limitations of my self-imposed rules. Finding related files when editing the rapidly growing codebase was becoming a chore.
Hmm.. Was that function in /API/Controllers/Message.pm? /API/Validation/Message.pm? /Web/Controller/API/Message.pm? Anyway, time for lunch
The Solution:
These are the plugins that helped increase my productivity as a developer.
1. Ctrl-P
Ctrl-P is a Vim plugin that allows for fuzzy file matching within Vim, and limits its search to the root of the git repo that you are currently working in.
Press Ctrl-P when in normal mode, start typing the filename and available matches will start appearing as you type. Typing ‘Message.pm’ would have found all of the files in the above example. Highlighted matches can open in a new tab, split or vertical split.
The ack plugin is really valuable when searching through a large codebase. This lets you search for text in files from within Vim (using ack as a backend) and have the resulting matches appear in a panel below your code.
ag is a much faster version of ack, and makes this plugin infinitely more useful. Use ag with ack.vim by adding the following to your vimrc:
if executable(“ag”)
let g:ackprg=“ag –nocolor –nogroup –column”
endif
One thing I missed with ack.vim was the ability to automatically sandbox your searches to your current repository, which is one of the things I love from Ctrl-P.I hacked together the following to get this behavior with ack.vim:
function! Rack(args)
let l:gitDir = system(“git rev-parse –show-toplevel”)
if l:gitDir =~ “Not a git repository”
execute ‘Ack ’ . a:args
return
endif
execute 'Ack ’ . a:args .’ ’ . l:gitDir
endfunction
command! -bang -nargs=* -complete=file Rack call Rack(<q-args>)
Once added to your vimrc, ‘:Rack Foo’ will search for Foo, sandboxed to the root of your git checkout.
3. vim-go
At BugReplay we opted to use Go for programming our backend.
Unlike some of the weakly typed scripting languages I’d used in the past, Go offered a rich set of tooling. Vim-go takes full advantage of this and makes Vim feel a lot more like an IDE, while still avoiding the bulk that a full IDE adds.
Vim-go autocompletes member methods and field names based on type. It even displays the full function signature in the autocomplete list.
This is far more useful than the rudimentary autocomplete that vim offers out of the box, which essentially just autocompletes based on words used previously in any open buffers.
Vim-go can take you to the function definition of the class/function your cursor is currently on, either in a split or new tab. This makes jumping through related files a breeze. It can also open the function’s documentation.
4. SuperTab
In order to get the autocomplete support based on type that was mentioned above, I had to move on from vim help’s 4 line tab autocomplete function to something a bit more robust. I opted for SuperTab since it didn’t require crazy dependencies to use and still felt somewhat barebones.
Even though backend work is more my forte, I’ve been writing a good amount of JavaScript at BugReplay.
Since the last time I wrote a considerable amount of JavaScript was almost a decade ago, I needed something that could easily catch JS errors while coding. Syntastic excels at this.
It can be configured to support multiple languages, so I can get inline errors for both JavaScript and Go. Being able to have a tool yell at me before I even tried out my code has been extremely helpful, and has made me a better JavaScript developer.
Occasionally, when a file takes a bit longer to open or save or Syntastic spews out a less than helpful warning, I’ll miss my original spartan setup. However, the improvements to productivity far make up for the added bloat
6. Storing your vimrc and other config files on GitHub
My original plan was to keep Vim vanilla so that I could work on any random terminal, but storing your configuration in the cloud makes setting up a new box with your preferred configuration and plugins fairly painless.
Conclusion:
When working on a large codebase, a lot of cognitive complexity goes into remembering file paths, or function/class definitions, or even correct language syntax.
The above tools allow me to keep less minutiae in my head at any given moment, so that I can focus on the actual problem I’m trying to solve.
