Source: tmux.orgSource: tmux.org

For the past two weeks I’ve been remote pairing using Vim and tmux, a terminal multiplexer, allowing multiple users to share multiple terminal windows. Vim is… Vim. You know — Vim. If you don’t know what Vim is, fire up Internet Explorer and use the Bing Bar to search for “Vim.”

TL;DR – tmux works well for terminal-based technologies

tmux is working pretty well for us as remote pair programming screen sharing technology for our terminal-based development tools. We gave up some MacVim functionality and had to learn (and keep remembering) a few new commands when using tmux + Vim. tmux is of no help for GUI-based tools, such as robust IDEs and web browsers, for which we still use Screen Sharing.app, if a bit awkwardly. For certain teams, tmux + Vim + Screen Sharing.app is a viable development setup, though with more overhead than pure Screen Sharing.app.

Pros

  • Negligible network lag for remote the developer.
  • No special firewall setup as long as you have ssh access to the host.
  • Cross platform between Unix, Linux, and OS X based systems.
  • MacVim users will find Vim very familiar.

Cons

  • Have to learn and use the tmux commands for screen navigation, scrolling, and more.
  • Does not help with GUI tools, such as browsers and IDEs.
  • Vim not as customizable as MacVim — MacVim users take note.
  • Likely higher overall overhead and impact to the pair.
  • Still using Screen Sharing.app for some tasks, but awkwardly.

Keep reading for more details.


Switching Offices: Hello Lag!

As a remote developer I work with one of our physical offices on software projects. Often, my “base” office changes when I switch projects. I switched offices once again for my current project, where elusive network gremlins have taken up residence. The upshot: my preferred screen sharing solution, Screen Sharing.app, is too laggy for maximum productivity.

Enter tmux + Vim

My new project adopted Vim (well, MacVim) as the code editor of choice. Other remote developers on our team had already established tmux + Vim as the remote pairing tech for this project for terminal-based tasks, such as coding, managing servers, and running tests, and Screen Sharing.app for GUI-based tasks. I jumped on the bandwagon.

tmux + Vim: The first 14 days

Here are my initial thoughts on the tmux + Vim remote pair coding combo. I’m planning on posting follow up articles as time goes on.

What Lag?

The first thing I noticed is that there is very low network lag when using tmux. Low network lag is tmux’s #1 win for the remote developer. Network lag using Screen Sharing.app + MacVim was very frustrating.

MacVim is Vim

MacVim is Vim. Switching from MacVim to Vim was an easy transition… mostly.

MacVim is not Vim

MacVim isn’t Vim. We have tweaked our .vimrc to use the ⌘ (Command) key, which doesn’t work for tmux + Vim because ⌘ is handled by OS X instead of Vim running in the terminal. We added additional key mappings that mimicked MacVim’s ⌘+[whatever] to <leader>+[whatever]. We had also set up MacVim to have different background colors for insert vs. navigation mode; we lost that, too.

tmux Overhead

tmux lets you share multiple terminal windows, but with that that comes with some additional overhead. You have to enter a special tmux-command-mode to manage tmux, such as creating, switching, and closing shared tmux windows. There aren’t too many commands to remember (or reference) — print out the excellent “$ cheat tmux” cheat sheet.

Scrolling Sucks

It really does. tmux’s scrolling buffer is not the same as your terminal’s scrolling buffer. You have to enter tmux’s goofy “copy” mode and use the movement keys to scroll around. Control+c exits this mode, which is counter-intuitive, especially if you are scrolling through the output of a foreground-running program which you would also exit using Control+c.

Impacting my In-Office Pair

I’m particularly sensitive to my impact on my in-office pair. Maybe that’s the Idaho in me — don’t be a burden. Ideally my pair has to make minimal changes to accommodate remote pairing: Skype and a headset. This is one of the reasons why I like Screen Sharing.app. As you can see from the list above, MacVim users switching to tmux + Vim have to make quite a few adjustments, albeit small adjustments.

Using GUI Tools

Coding isn’t everything. My pair and I tweak and reload our site dozens of times per hour, do research, look at design mockups, check Pivotal Tracker, and perform countless other non-terminal tasks throughout our day. tmux doesn’t help those tasks.

The Secondary Monitor

I still use Screen Sharing.app to perform GUI tasks on my pair’s computer, though in a somewhat awkward way. Our workstations have two monitors: one used for the main coding windows, the second for everything else. I use Screen Sharing.app to view my pair’s secondary monitor, which has the web browser loaded with our ever-changing site under development, Tracker, and other stuff. The problem is that I cannot see the OS X Dock, or see the application-switcher when I press ⌘+tab, a key-press I use habitually. In other words, it’s hard for me to switch apps on that secondary monitor.

Here’s another frustration: When I switch to Screen Sharing.app and see my pair’s browser, I automatically press ⌘+r to refresh the browser’s page. The problem is that the browser is not actually my pair’s foreground application — Terminal or iTerm is, since he’s been coding in Vim with me. ⌘+r messes up my pair’s Terminal/iTerm screen every time. I’m forcing myself to always use the “reload” browser button instead.

I’ll post a follow-up in a few weeks outlining the tmux + Vim learning curve and any changes we’ve made to our process.


Resources and Links

Other developer’s blog posts about tmux + Vim or screen + Vim:

blog comments powered by Disqus