How Pivotal Labs use Tmux for remote pair programming | Hacker News Reader

How Pivotal Labs use Tmux for remote pair programming

pivotallabs.com

113 pointsjodosha31 comments

I'm going to once again praise the Pragmatic Programmers tmux book by Brian Hogan[1]. It's an absolutely amazing book. Short enough to make it a quick read, but filled with everything you could possibly need. It gets right into the meat and potatoes and by the end of the first chapter, you can be using tmux effectively.

I highly recommend the book. Absolutely love it.

[1] http://pragprog.com/book/bhtmux/tmux

If any screen folks are trying out tmux, here is my .tmux.conf assembled to have screen like bindings.

https://github.com/rahulkmr/dotfiles/blob/master/.tmux.conf

C-a c new window

C-a | vertical split

C-a S horizontal split

etc etc.

As far as copy paste goes, I use this https://wiki.archlinux.org/index.php/Tmux#ICCCM_Selection_In... C-a C-c copies tmux buffer to clipboard, C-a C-v sets tmux buffer to clipboard and pastes it(it's already in the configs; just putting it here).

As far as terminal emulators go, I have tried out a lot of them(gnome-terminal, konsole, urxvt, xterm) and finally settled on terminator. gnome-terminal will keep messing with my readline settings(alt opens up the menu), urxvt won't let me copy-paste the clipboard...Terminator is no frills - you can graphically set the preferences, or have a config file; it lets you copy paste to and from the clipboard; you can configure it to copy the x-selection to clipboard(middle click to paste - just not it). For anyone looking for a terminal emulator on linux(or whatever other platforms it runs on), I highly recommend it.

Long time screen user here, and with all the screen-like tmux configs I always miss one thing.

When I create a couple of windows and I split one of those into 2 panes, I couldn't manage to move panes from one window to another. In screen, apps you run are absolutely detatched from any visual configuration, and everything is reachable from everywhere.

It's a bit difficult to explain, but I'm sure some screen users will understand that situation. That is what also got me hooked to ratpoison[1] wm.

[1] http://ratpoison.nongnu.org/

I covered that in the tmux book briefly - you want the join-pane and break-pane commands. By default, prefix ! will break a pane into a new window, and join-pane will let you move a pane to a different window - you have to specify the window number and the pane.

Does that help?

Thanks for the suggestions!

Yeah, this kind of works, but I need to do maybe too many steps to get what I want, maybe with some tmux scripting fu I'd make it work.

The main issue is that I can open my apps always in the same order, so I know wich window number it has, then, joining-pane by window number would be doable. the problem is that after breaking and joining a few times, numbers may get scrambled.

Another issue is that if an app is in a pane, it looses the identity, and cannot be joined to another window alone.

I'm thinking on doing something in the lines of:

WINDOW=`tmux list-windows | grep active | sed -e 's/^$.$.*/\1'`

choose-window "join-pane -s $WINDOW -t %%"

But for the moment, no luck.

Will keep trying :)

I had similar issues to yourself when migrating from screen.. the notion of 'panes' ~= 'windows' doesn't really work in some sense.. in screen when you split you initiate an empty 'pane' (if that makes sense).. and then you put some content into it.. you can also move the 'windows' around to wherever you want.. but all within a single 'pane'-buffer

however, in tmux.. what you have is like a whole series of pane containers.. these are called windows.. now, each window can have a name.. whilst a pane on its own does not.. you can fortunately 'join' and 'send' panes between windows.. also, another thing I tend to find useful is the ability to 'break' a 'pane' out've its current window and devote a full window to it..

the .tmux.conf bits you need are

bind-key 'j' command-prompt -p "join pane from:" "join-pane -s '%%'"

bind-key '@' command-prompt -p "send pane to:" "join-pane -t ':%%'"

whilst :break-pane (or ^b ! by default) allows you to send a 'pane' away to its own window.. (apologies it that sounds awfully convoluted/confusing)

That's what I was thinking of :). Thanks!

Maybe that's as far as we can get by now with it. Luckily tmux is heavily developed so there's hope for that workflow being easily usable in the future.

GNU Screen http://www.gnu.org/software/screen/ also supports multiple users per session, so you can use it for remote pair programming as well. I believe it supports most of the same things as tmux except the vertical splits (although I seem to remember there being a patch to add that). I'm not advocating one over the other, I'm just a long-time, happy screen user who's never taken the time to investigate tmux.

Screen is to tmux as a Ford Taurus is to a BMW

Screen is nice, sure, but tmux has a couple of tricks up its sleeve.

And if your net connection is a little shaky, tmux can save your sanity (whereas screen just hangs there)

Care to elaborate? I'm open to switching if I think it'll be worthwhile.

If you do a shared session tmux has one feature that was a big deal for me when comparing to screen. tmux will use the intersection of terminal resolutions of users in the session, whereas screen will use the resolution set by the creator of the session, which easily results in a too-large and unusable display for the other user.

Just took a screenshot to show it off, easy to understand when you look at this: http://dl.dropbox.com/u/191376/Screenshots/mb06.png

Personally I switched because I could read tmux config as opposed to screen's, and tmux is shell friendly. I use ubuntu and the default screen there has vertical panes for a long time, so that doesn't factor in.

tmux being shell-friendly means I write one shell script for each project, and if I restart the system for some reason, I open the terminal and run tmux-foo. tmux-foo creates a session, cds to project root and create multiple windows, opens vim in one, rails s in another, logs in another, rails console, dbconsole etc etc.

If you are curious, pick a config which gives you screen like keybindings(tmux uses c-b; I swore to screen long back I would use c-a) and try it for some time. As far as user experience goes, you have everything you had in screen with some added benefits(no, it isn't bmw)

>you have everything you had in screen

...except for serial communication. Because I connect to various hardware UART devices all day, I need serial communication. I hate minicom and most of the other serial comm programs don't have the features I need.

Since I'm already using screen as my serial communication software, I go ahead and use it for terminal multiplexing and session management as well.

The best way to see the difference is to try it, it's basically "the same" out of the box, with the exception of Ctrl-B instead of Ctrl-A

(this makes sense if you use Ctrl-A as 'Home')

Also: http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ

Yeah if it's pretty much the same, then I don't really care to change. I'm used to screen and happy with its functionality. Vertical splits aren't game-changing enough for me to learn a whole new app.

I love tmux, but it's crazy that they went to all the trouble of rebuilding screen without fixing one of the most glaring flaws to a newcomer: the guaranteed-to-conflict default key binding.

Screen requires setuid root to be used by multiple users. In tmux, permissions are just based around who has read/write access to the socket.

screen has vertical split but it renders so slowly it's not worth using.

just in case anyone isn't aware of it, wemux https://github.com/zolrath/wemux/ makes paired programming very easy to setup for tmux, many of the 'issues' discussed are also pretty solvable with a bit of googling..

there's various different work arounds.. a recent one I came across was to make sure your vim is compiled with +xterm_clipboard and +clipboard.. then doing "r+ allows you to paste directly from your clipboard using vim rather than relying on whatever your terminal emulator gets up to..

vim --version | grep clipboard to check how your vim was compiled

also, adding the following to ~/.tmux.conf is useful

--------------

#copy tmux paste buffer to clipboard

bind C-c run "tmux show-buffer | xclip -i -selection clipboard"

#copy clipboard to tmux paste buffer and paste tmux paste buffer

bind C-v run "tmux set-buffer --- \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"

I find this very interesting - having paired quite a bit with the Boulder office, none of them would have ever considered this setup. They where all Rubymine or GTFO...

Our pivots in SF weren't familiar with tmux or command line git (most command line tools, actually) at the beginning of our engagement.

SF was also predominantly RubyMine last I checked.

I was there last month, still predominantly RubyMine, but I did see some vim.

NYC office is almost entirely Vim.

I have also found screen sharing to be way too slow for remote pairing. A good bit of our development is in Visual Studio, though, and I haven't found a good way to remotely share an editor session other than screen share. For our Python/Ruby work I'll definitely try this out, though.

The limiting factor for desktop screen sharing is usually the upload bandwidth of the host rather than the download speed of the remote given that most (home) internet service packages are high download/low upload. For example, I have 60Mbs/down service and it didn't matter because our office had a completely saturated upload pipe. Thus my sweet download speed didn't help as a remote person.

If possible, upgrade the upload speed of the host or even arrange the pairing such that the person with the most upload bandwidth is hosting the remote pairing session. After an office network upgrade to 20Mbs/up desktop screen sharing -- that is, GUI-based and not ssh/tmux based -- is extremely fast and completely usable.

I will be speaking about remote pair programming at Pivotal Labs NYC on 08/02 at 12:45. If you can't join us in person join the livecast: http://www.livestream.com/pivotallabs

For anyone using Komodo, it has a similar feature that allows two people to have the same file open for editing at the same time. It works across servers (using smb) pretty well, but that probably depends on your network speed.

tmux + iTerm2 are the best things ever (except for the copy/paste issues).

This is worth a little more elaboration, I think. If you compile the iTerm2 version of tmux provided on the iTerm2 website (a merge of the fork into tmux proper is pending), then you can link iTerm2 natively to a tmux session.

This means that the iTerm2 window size is the tmux window size; tabs in iTerm2 are tabs in tmux. Horizontal and vertical window splits in iTerm2 are the same in tmux too. And all of this is bound to the GUI, so resizing/reordering panes with your mouse makes the proper modifications in tmux. And because this is a 1:1 mapping of functionality, others using the same native integration will see tabs and split panes get added and removed in real time, as someone on another machine does it.

It's still in early stages and definitely not bug-free, but this is absolutely the best multiplexing experience I've found. Unfortunately, because this is specifically for iTerm2 right now, it's not cross-platform.

I would love it if gnome-terminal did the same thing. It should be possible to do the whole tmux thing without having to know any keystrokes, configuration etc and just use your existing gui terminal program.

Reply on news.ycombinator.com