
How Pivotal Labs use Tmux for remote pair programming - jodosha
http://pivotallabs.com/users/joe/blog/articles/2199-how-we-use-tmux-for-remote-pair-programming-
======
jasonlotito
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>

------
irahul
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...](https://wiki.archlinux.org/index.php/Tmux#ICCCM_Selection_Integration)
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.

~~~
rgrau
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/>

~~~
bphogan
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?

~~~
rgrau
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 :)

~~~
q_revert
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)

~~~
rgrau
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.

------
Davertron
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.

~~~
raverbashing
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)

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

~~~
raverbashing
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>

~~~
Davertron
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.

------
q_revert
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"

------
grammaton
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...

~~~
bdunn
SF was also predominantly RubyMine last I checked.

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

------
Tashtego
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.

~~~
joemoore
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.

~~~
joemoore
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>

------
debacle
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.

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

~~~
TomFrost
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.

~~~
rogerbinns
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.

