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.
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.
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.
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
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...
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.
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.
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.
[+] [-] jasonlotito|13 years ago|reply
I highly recommend the book. Absolutely love it.
[1] http://pragprog.com/book/bhtmux/tmux
[+] [-] irahul|13 years ago|reply
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.
[+] [-] rgrau|13 years ago|reply
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/
[+] [-] Davertron|13 years ago|reply
[+] [-] raverbashing|13 years ago|reply
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)
[+] [-] technomancy|13 years ago|reply
[+] [-] zemo|13 years ago|reply
[+] [-] q_revert|13 years ago|reply
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|13 years ago|reply
[+] [-] derwiki|13 years ago|reply
[+] [-] bdunn|13 years ago|reply
[+] [-] Tashtego|13 years ago|reply
[+] [-] joemoore|13 years ago|reply
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.
[+] [-] debacle|13 years ago|reply
[+] [-] gbrindisi|13 years ago|reply
[+] [-] TomFrost|13 years ago|reply
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.