If you're willing to spend $14 for a more detailed tutorial, I'd strongly recommend _ tmux: Productive Mouse-Free Development_ from The Pragmatic Bookshelf.
It goes through common use cases, common customizations, and pair programming.
I do not get the idea of buying a "book" to learn a *nix utility that explains itself in a single man page when all you need to learn is just a few keyboard shortcuts.
Obsessively focusing on the tool does not magically improve productivity.
A manpage doesn't help you arrive at a workflow or show the forest for the trees or give field advice from someone that uses the tool or reveal ways to integrate the tool with other programs.
No but 45 minutes using it will. Not saying this book is no good, but 90% of tech books on softer subjects like this aren't worth the paper they are printed on. They hark back to the day when I first walked into Sun and saw a dozen volumes xn versions for the xmotif and xlib reference manuals.
I know! It's really bizarre. It's almost like some people have different preferences from you or something. Let's spend more time talking about how people with different preferences are weird and stupid.
Boy I sure hope not. In case there are, let's continue to imply that they're making poor choices. While we're at it, let's also shit on other people's work which we haven't read so that we can make sure that as many people as possible can feel our contempt. Especially when the authors of said work are right here, right in this very thread!
The annoying thing about all these eBooks is that the effort would be better spent improving the manual pages for the existing product rather than yanking a few dollars out of some people for some "special treatment".
man pages aren't tutorials. While it pays to go through the man pages of certain essential utilities, not all man pages are created equally. Try reading ffmpeg's man page to learn how to use it. But its indispensable once you learn your way around the command.
Sure but hey, if you buy the version from Amazon, you're only getting 1/3rd of the product, too. I can't guarantee you get updates I push to the book, and you also don't get the epub and PDF formats.
But yes, I get more money because there's no Amazon middleman. Even if it was the same price on Amazon, I'd get less royalties.
I will always look for a book on amazon (as I know, from working for a publisher that amazon demand cheaper books). As a consumer why would I act any different?
If you push an update, I can buy that as well on amazon (and still only spend $14.40 total)...
EDIT:
1/3rd of the product? do you mean there is only 1/3rd of the book? or are you referring to the formats? That is an odd way to describe the product. I would say the product is your knowledge, not the paper/format it is produced in.
I wasn't objecting to giving him/her money. Just that there is a 100% price difference between amazon and prag prog (something that the author left out of their comment).
If he/she doesn't like amazon's price... then don't sell on amazon.
Thanks for the question on byobu - I wasn't aware of it. Not sure what you're asking about though. It appears byobu adds status information -- it doesn't seem to change the aesthetics of the terminal?
i hacked few bits of ugly code. this patch allows tmux to pass through to terminal 24bit colours (Konsole supports): https://gist.github.com/ArnisL/6156593
Terminal multiplexers are great if you're stuck in SSH, working without a window manager at all, or have a real need to share a set of terminals with multiple people at once.
But if you're hacking together a desktop environment with tiled terminals, status bars, keyboard shortcuts, dynamic or static layouts, and the ability conceal layouts on different workspaces (which is what most people's intent is when using detachment), then just get a tiling window manager already.
I agree wholeheartedly. Take what you love about tmux and extend it to include all applications. In addition to terminals (rxvt-unicode-256color) I run Firefox with Pentadactyl. With wmii (my tiling window manager of choice) I have keyboard-free navigation between vim and Firefox.
I don't buy into the remote development over SSH method. Servers with as much horsepower as my ThinkPad with an i7, SSD, and loads of RAM cost a lot, and I can't stand latency on my terminal when I'm working hard.
For me it has been the last brick in date in my terminal-based IDE, which is made of zsh/vim/ssh/tmux.
Everything is running on a remote dedicated server, and I can access my dev environment wherever I can find an internet connection and launch a ssh tunnel (which is, in my case, almost everywhere I would find myself wanting to work).
In that case, tmux's sessions are god sent.
I would have say the same for screen before, but with Tmux you can have this sort of niceties : https://github.com/Lokaltog/powerline. Basically, it's a statusline with bells and whistle.
I use Terminator (http://www.tenshu.net/p/terminator.html) primarily on local machines instead of screen/tmux(or byobu). I get the added benefit of scrolling.
I tend to copy paste a lot from log tails etc into my my text editor for quick searches or other things. The infinite scroll feature(with a scroll bar) helps me out a lot. In tmux/screen i still haven't figured out a good workflow to copy a few screenful of content.
On servers i tend to use Byobu bindings which now use tmux(used Gnu screen some time ago). It has good defaults and some help for newbies to get used to.
If you're in copy mode in tmux - prefix [ then you can use emacs or vim keybindings to do your selection and copying, and then it's just prefix ] to paste into an editor. If you're comfortable selecting a few pages of text with Vim, it doens't take a terribly long time to get used to doing it with tmux.
That said, use what makes you productive, and be happy!
You can use the mouse wheel to scroll and highlight to copy. I think you are specifically trying to say the mouse highlight won't go past one window though, right?
I knew I saw a way to interact with it through the mouse. Thank you for reminding me. `tmux` is really a neatly little program, everything is there, simple and efficient.
ps:
man tmux | grep "mouse-" # shows the mouse related options
C-b : "set mouse-<option> on"
pps: turning on mouse windows/panels interactions disable text selection, do you know a way to have both ? (beside switching beside custom defined modes on your .conf)
You can always do text selection in a terminal by holding shift while selecting the text, no matter if the program running in the terminal supports mouse or not. I think on some terminals it's alt instead of shift.
This is the exact workflow we use at my company as well, and we've all grown to love it.
I got a new laptop today, and because we do all our dev on a remote server via ssh, tmux, and vim, it only took a few minutes to get my new machine set up for development. All I had to do was download iTerm and copy over my private key and config file! So easy.
I've seen this referred to as "Unix as an IDE". Big fan.
I highly recommend byobu. It acts as a front end to tmux (or screen) and provides some nice functionality like a status bar and various default keybindings that are consistent.
I use byobu pretty heavily and love it. Even if you don't venture too far into the scripts etc it's incredibly handy to fire up on a server and have multiple panes whilst working.
I've seen this before, it was immensely helpful for moving from a multi-window workflow to a single window with tmux. The tmux docs themselves are a bit obtuse and don't do a very good job explaining the various concepts tmux uses.
Looks like the author only uses one session he calles "work". What I really like about sessions is that it allows for isolated contexts which are easy to switch (prefix-s get prints you a nice list [1]).
Right now I have seven sessions open [1]. Three are work projects (they usually have windows for vim, db console, etc.), two are university courses (vim, matlab), in one session I'm learning some Haskell, and in the last one I'm working on an open source ruby gem. If I had all these windows in one session only, I'd constantly be switching to the wrong windows.
> What I really like about sessions is that it allows for isolated contexts which are easy to switch (prefix-s get prints you a nice list [1]).
I always end up doing the same as the author (out of bad habit), when I should really be using windows more often (to split out dev work, irc, uni work, etc). It's good advice and stops the too-many-windows problem.
Also: what theme are you using in that screenshot?
So I wrote a book on tmux and use it every day, but I use i3 on my Linux box.
The main difference? tmux is a terminal multiplexer. So it's not going to handle the web browser stuff at all. Other than that, it's like Screen.
A lot of devs spend a lot of time in the Terminal, running scripts, background servers, etc. With tmux (like Screen) you can have them running and detach, and come back later.
Even with i3 I still find lots of room for tmux in my workflow when I'm in that environment.
tmux is also a hell of a tool for pair programming, and for managing remote servers.
But yea, if you're happy with i3, and you're using that to do Terminal splits, that's probably pretty great as is. tmux will remember the current working dir when you open new splits, and you can script it to launch your project workspace, but that's kind of just icing.
I can answer tangentially as a screen user for a couple decades that if you put something like
if [ -n "$SSH_TTY" }; then
exec /usr/bin/screen -xRR
fi
in your .bash_profile then where ever in the world you log in via ssh, you'll instantly have exactly the same environment, as if you never disconnected. Simply "Ctrl-a z" to disconnect and later reconnect "somewhere else" exactly as if you hadn't disconnected.
You can do something kind of like that with a tiling window manager if you put VNC in between the user and the window manager, such that all access is via VNC. However VNC doesn't transparently remap like screen does, so you can get icky issues with mismatched screen resolutions in VNC. In that way screen/tmux is MUCH better than doing something kinda like it with VNC. OR rdesktop, or whatever.
In .screenrc I'd suggest startup_message off, vbell off (because I don't like it), and some lines similar to bindkey -k k1 select 1, bindkey -k k2 select 2, so that function keys insta-switch you. Also I have a "caption always" line that resembles line noise but it begins with the hostname and shows exactly which sessions I've opened and highlights the one I'm looking at right now. I probably last messed with it 15 years ago so I don't remember how it works.
You can put lines in .screenrc like "screen -t bash 0" to autorun a bash shell in screen 0. You could put something like "watch procinfo" in screen 0, or tail something, or whatever.
For all intents and purposes screen overlaps tmux about 99.99%. There is a small 0.01% area where featuresets and bugs do not overlap. There's a cultural thing where "most" screen users know about screen and tmux, and "most" tmux users don't know about screen, which is mildly interesting.
Maybe, but personally I find that terminal windows are the only thing I tend to want to split the screen for. Almost everything else I prefer to run in full screen. If I had a 50" screen or something, I might feel differently, but with two smaller screens the two separate screens offer enough tiling for non-terminal windows.
I was planning on installing a tiling WM when I got my last laptop (I used to use Ion, so I'm used to the concept and wanted to give it another go), but frankly as much hate as Unity gets, once I had Ubuntu installed I realised that with some keybinding tweaks it was sufficient.
To be fair, in your the OP's case at least your editors are included in the terminal category.
For me I find that even on 25" screens full screen is usually too much. I prefer to split at least once for every screen now. It was different when monitors were 4:3, though. I made things full screen all the time and was happy with it then.
I'm not 100% happy with tiling WMs though, tbh. I find their focus on being completely mouseless and minimalist integration-wise kind of limiting.
Since this article was written in 2001, iTerm2 has implemented support for the tmux protocol, so windows, panes, scrolling etc. happen at the GUI level instead of the terminal level. Kind of the MacVim of tmux.
Tmuxinator is an awesome gem that extends tmux to allow you to set up specific sessions that can be booted up. You can customize panes, pick specific apps to run in each, and there's tons of customization that can be done: https://github.com/aziz/tmuxinator
Newer versions of tmux have an expand pane command mapped to Leader-z. It will grow the pane to full size, do your xopying then leader-z to toggle back to your normal split view.
If you don't mind trailing whitespace block select might be an option (option + select on OS X / ctrl + alt + select on Linux). Or just use copy mode and yank the selection to the system clipboard.
I've been seeing tmux posts a lot the last couple of years, but I can't pull myself away from screen which I've been using for what almost a decade now?
It has a higher chance of being installed by default on a remote system I don't have root on, and works just fine for everything I need so I haven't had a reason to switch yet.
i switched over just a couple of weeks ago, and i've got to say, i really like tmux. i just find it a little more flexible with regard to split layouts, etc.
I have learned to be careful about any long running or interactive processes that end up out-of-sight-out-of-mind. I accidentally left a db connection open in one of my tmux windows and our staging db didn't refresh for 2 days haha.
(And I immediately started debugging in the wrong places, of course.)
I like being able to shift+pageup in consoles to see history, but haven't got a good replacement for this in tmux. (Including when you switch to a new window and want to see something.) Usually I go into copy mode and scroll up. This works. But maybe there's a better way. Anyone know?
I guess you know this, but just for some context: ctrl-a is the default prefix for GNU Screen which was the unopposed leader in terminal management for a long time, so most people are just used to it.
As for the ctrl-a shortcut, I admit I use screen/tmux for mail, jabber and text editing/programming mostly, so I do not spend that much time in the shell where that shortcut would be handy. I just didn't use that shortcut until now.
A while ago I changed my prefix to ctrl-q because of ctrl-a interfering with me being able to move to the beginning of a line. Not sure if I would go back to ctrl-a now, but this is nice to know.
I don't - I use ctrl-s instead. Similar position so just as easy to hit, but it seems to clash with fewer important terminal keystrokes as it has been historically used for flow control in the terminal driver. Here's the relevant bit for .tmuxrc:
unbind C-b
set -g prefix C-s
bind s send-prefix
bind C-s if '! tmux last-pane' last-window
I've used screen for donkey's years now and since I'm also an emacs user, the C-a as the prefix (default for screen) was out of the question. C-] was my solution and has worked dandy so far without ever clashing with any keyboard shortcut from any application.
It goes through common use cases, common customizations, and pair programming.
http://pragprog.com/book/bhtmux/tmux