vim and tmux: why and how

vim, tmux and ssh are powerful tools every developer should have in their arsenal. This post explores the advantages of each, and ends with a set of configuration files which standardize the keys used to perform actions common to both vim and tmux. Future posts will explore ssh tunneling and remote pairing.

Why vim?

Nothing polarizes developers quite like a theological discussion about which text editor is best. These rivalries used to center around vi and emacs, text-only editors created when you were probably still a zygote. Since then, editors such as SlickEdit, TextMate, Sublime, and Github’s up-and-coming Atom have all provided pretty and easy to learn GUI alternatives to the arcane commands required to drive console-based editors.

These editors have two things in common: they all offer support for vim-based key bindings, and none have managed to unseat vim as the editor of choice for serious development. That level of fanaticism is usually reserved for Apple products [overpriced and slipping under Tim’s tenure] and political parties [they both suck]. So what accounts for vim’s staying power?

vim is omnipresent

At some point, you’ll have to edit text files on a remote server, and vi comes standard on all Unix distros from A/UX to ZeroShell. Often it’s the only editor available. It’s also available for Windows, mainframes and Amigas (which is where vim got its start). Store your config files in Dropbox or Github, and you can share settings and plugins across all of these platforms.

vim is omniscient

Whatever bleeding-edge language, DSL or framework you’re using, there’s likely very good support for it in vim. Syntax highlighting, jumping to definitions across multiple project files, autocompletion, snippets, and other niceties are just a plugin away. And if not, it’s not too much of a chore to create them.

“There’s a plugin for that”

I switched to vim full time once I realized it was more stable, better supported, and much faster than Sublime, and I didn’t have to give up a single feature. Want to browse project trees? Save and reload all of your windows and tabs? Jump to source of imported code? Kick off tests from inside the editor? Fine tune your window and tab management? Integrate with Github?

Think up a feature. Any feature. It’s been implemented, and it’s better than what you thought up anyway. There are often multiple competing solutions to choose from. This can be intimidating at first, but package managers allow you to find and try out new plugins, and vim’s integrated help system is a great resource for learning about each plugin in-depth.

Leave your laptop (or desktop) at work

You’ve got 7 consoles open. Two are running app servers, two are tailing log files, two have vim running with multiple tabs and windows that hold everything related to the issues you’re trying to resolve, and one has a scrollback buffer you don’t want to lose.

If you’ve opened those consoles from within tmux, you can use SSH tunneling to reattach to them from an iPad in a coffee shop or your home computer and pick up exactly where you left off. Yes, even without VPN access. And because it’s all text-based, its perfectly usable in that coffee shop with the crappy WiFi.

Remotely pair on issues with tmux

Want to pair-program over a low bandwidth connection? Good luck getting Google Hangouts, Skype, VNC or even ScreenHero to cooperate. Again, tmux to the rescue. The remote person simply SSH’s to the server you’re working on, attaches to the same tmux session you’re using, and shazaam! You’ve got shared access to terminals and editors. Hopefully you’ve also got unlimited minutes so you don’t murder each other over who owns the cursor.

Getting Started

There’s no shortage of resources on the web to help you learn vim, from interactive tutorials, wiki tips, screen casts, and of course print and ebooks. But how do you get started?

Many users start with an IDE-like monolith like SPF13. And then they’ll either give up on vim altogether, or (what I would recommend) they start over with just vim and a package manager such as Vundle. Add plugins only as you need them, and take the time to learn how to use them as you do.

Over time, you’ll notice that some plugins have key combinations that conflict with each other, or are difficult to remember. I found this to be true when running vim inside of tmux as well. Both vim and tmux allow you to create multiple tabs, split panes within those tabs, resize them via a mouse or with key commands, toggle maximizing them, reorder them, and even rename them. Unfortunately they don’t share terminology: a tmux pane is a vim window, a tmux window is a vim tab, and so on. Worse, the key bindings to manipulate these vary wildly.

Happily, tmux, vim and even vim plugins allow you to redefine key bindings. The Holistic vim and tmux project is a set of config files which do exactly that: the “leader” key in vim is a backslash, and the leader key in tmux is CTRL-. Want to go to a tab? 1-9. Rename a tab? =. Open a tab? t. Close is c. Split is s. Vertically split is v. It’s a great way to learn to use both quickly, and the config files are easy to understand and update.

So here’s one more way to get started: Fork it on Github, turn off the plugins you don’t want or need yet, and then never stop making it your own!