* Resizing panes will now reflow the text inside them.
Finally! I did not expect this feature, I thought the author was opposed to it. It is the one thing I have missed from screen (and part of the reason why I originally started using screen, since xterm does not reflow on resize either).
AFAIK there are tmux 'windows' which are like tabs and 'panes' which are vertical and horizontal splits in 1 tmux window
but assuming you mean 'panes', it seems you can:
Ctrl-b o
to move around the current window's panes clockwise. Although I prefer inputing a given direction like the other replier suggested with arrow keys.
For me moving between windows and panes is something that I do a lot. So much so that I removed the need to use the 'tmux prefix' to do so. In my ~/.tmux.conf I have for window and pane switching:
# set pane switching with <alt>{U, E, N, I} for up, down, left, right and respectively without needing prefix
bind -n M-N select-pane -L
bind -n M-I select-pane -R
bind -n M-U select-pane -U
bind -n M-E select-pane -D
# set window switching without needing prefix
bind -n M-a select-window -t :1
bind -n M-r select-window -t :2
bind -n M-s select-window -t :3
bind -n M-t select-window -t :4
bind -n M-d select-window -t :5
bind -n M-h select-window -t :6
You can just replace the keybindings I chose like M-a (alt-a) to something that works for you. If you want to keep using a prefix (incase you are worried the keybindings will clash with other program/system bindings), remove the '-n' flag. Hope that helps.
I also did the thing to get rid of the tmux prefix for pane switching. But since I don't use the function keys, I mapped keys F1 through F9 to various tmux functions. F1 = next pane, F2 = prev pane. One less key to press. :)
It binds the function keys which makes life so much easier. F2 starts new window, F3 and F4 rotate back and forwards. It also has a pretty neat status line.
Well the easiest way is either to wait for it to appear in the repos or wait for someone to package it and put it into a PPA. However, it doesn't have that many dependencies, so building it yourself is another not too stressful option.
Yes, formally. You don't have to specify -z in GNU tar today, you can just say -x and it'll add -z or -j for you -- it figures out on the fly if the archive's been compressed and how. Very convenient.
instead of make install, consider checkinstall or fpm so that you are properly integrated into ubuntu's native package manager (dpkg). Doing so will save you headaches when you want to uninstall tmux or upgrade later.
I continue to be amazed by the people who install "random binaries" via PPA.
I guess I assume that if you want cutting-edge packages you'll use a cutting-edge release/distribution. If you don't, and you want something more recent then it seems to make sense to make your own packages, or install locally via gnu-stow, or similar.
You're going to open a big can of worms with that one ;). Tmux has quite a few more features than Screen, with Screen having a few features that are useful in edge cases[1]. It's hard to argue with tmux having bindings for vi/Emacs, as well.
If you're on a mac and use iTerm2, using tmux is somewhat of a no-brainer, thanks to the integration between tmux and iTerm2[2].
With reflowing text added to tmux, and giving that "Lots and lots of bug fixes, fixing memory-leaks, etc." the benefit of the doubt, then I would say that unless you have a specific use case of screen (and if you do, you know it) then you should be using tmux.
After mastering screen, I switched to tmux. It's a lot easier to configure. It's also a lot nicer to split panes etc...
Definitely recommend the switch. You might be dreading it, but two days into tmux you won't regret it. It took many weeks trying to convince myself screen is better until I actually tried tmux out.
The only two pains that come with it are a) having to type `` to get a single `, and b) pasting anything containing a backtick behaves as if you'd typed it out.
I use vim-slime[1] to send strings to other panes in tmux. I never type anything directly into a REPL. I just send my code from Vim to it. It's amazing with lisp or python. (A little less amazing with php, as the php repl IS AWEFUL)
"What is a terminal multiplexer? It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal. And do a lot more. See the manual."
That's awesome. So many times someone posts on HN "CaffBook.ly.errr 0.98 now released" and I have no idea what it is or why I would want it.
Some of it is arguable, but for me one of the greatest benefits is how tmux will auto-resize to the smallest terminal connected, making it useful for screen sharing or when connecting to an existing session from a mobile device.
For me, tmux has saner options and more mnemonic default keyboard shortcuts, that do not interfere with default bash shortcuts (Ctrl-A is goto-home-of-line in bash/emacs, but it is hijacked by screen by default as its escape sequence; tmux uses Ctrl-B for the same by default, which in the emacs bindings means go-back-a-character, and I do not use much, and is less likely to hit by accident).
I want to like tmux, I really do, but my main gripes are scrolling in panes with the scroll wheel and selecting / copy/pasting text. iTerm (osx) or Terminator (linux) handle that much better, although I admit they can't really be compared technology-wise.
Alternatively, I never figured out how to select / copy text just as fast in tmux / vim / etc as with the mouse.
* Control mode, which is a way for a client to send tmux commands.
> Currently more useful to users of iterm2.
With this, if you connect to tmux via iTerm2, you can get it to pop up a window with tabs for each shell in the tmux session. History via the mouse wheel is native, changing tabs is native, new tab is native. Essentially you don't need to know any of the tmux commands at all unless you connect from a terminal program that doesn't know the protocol.
tmux status bars are customizable(no surprises there I guess) and the powerline is one of the nicer status bar arrangements - https://github.com/erikw/tmux-powerline
i've switched from tmux to screen to byobu ( which is a wrapper for screen ) because of its simplicity.
screen also has very little problems, with tmux i always had time costly issues.
If you like tmux, also check out teamocil (https://github.com/remiprev/teamocil) to really enhance your use. It enables you to define tmux sessions via YAML, which is great for programmatically setting up a complex dev session. Mine, for example, fires up six panes in my preferred layout, and starts up a particular part of our project in each pane.
I used to use tmuxinator, but it's pretty much abandoned. There are pull requests that are over a year old. On the other hand, I submitted a pull request to teamocil and it was merged the same day.
I'll actually help maintain tmuxinator now. :) The project is really awesome but the author doesn't have enough time for it, so he added me to the project a few days ago. I'll go through the pull requests soon.
You could achieve the same thing with shell scripts, but one of teamocil’s advantages is that it gives you the simplicity of YAML to build complex layouts.
It's definitely a well-done, and I'll be pointing new users of tmux at it. I would have been all over it if I would have seen it the first time I dove into tmux's man page way back when.
If I get a chance, I'll give a go at converting the scripts for some of the layouts I use all the time, and see if it sticks.
These days it's very easy to use a simple api without knowing about the dragons lurking beneath the surface. Flip side of our "reusable components" holy grail.
I agree. It takes surprisingly few lines of code to make a nice wrapper with some shortcut aliases/functions to simplify the scripts. My whole tmux workflow is managed by about 30 lines of code to bootstrap by tmux session management: https://github.com/treyhunner/tmuxstart/blob/master/tmuxstar...
If you don't like the YAML format of teamocil or tmuxinator and just want to write shell scripts to do the same thing, check out tmuxstart: https://github.com/treyhunner/tmuxstart
I made it shortly after switching to tmux last year. I hope this kind of functionality will eventually be built-in to tmux.
Anyone know if it is possible to do single combination keybindings? Currently all of the keybindings are things like 'Ctrl+W L', whereas I'd like to do things like 'Command+L'?
If you use bind-key -n C-f some-tmux-command it'll bind directly to Contrl-f. The -n means no prefix. I don't know how you'd make tmux recognize the Mac's command key though.
I realise you can rebind them, but both screen and tmux do themselves a disservice by choosing binding keys which overlap with prominent keys in emacs and for users who use emacs mode in their shell.
First impressions count.
If you want to configure tmux to use just a backtick as the escape, create ~/.tmux.conf
unbind C-b
set -g prefix `
bind-key ` send-prefix
When you need to type a backtick just press it twice.
For screen, I used to do this:
escape ``
.. in ~/.screenrc, but I've just tried it and it seems that there's now no easy way to type a backtick when you need one.
Query: in screen I can switch between two buffers by doing ctrl+a, ctrl+a. This doesn't work in tmux. How do I configure this to work in tmux?
That's not quite what I'm after. I guess it's hard for non-screen people to know what I'm talking about from my vague description above :)
Here's a scenario to show what I mean: you're in buffer 5. You switch to buffer 2. Now if you do ctrl+a, ctrl+a, you leap back to buffer 5. And if you do it again, you go back to buffer 2. This is great when you're editing code in one session and running it in the other.
Is there a way to set it up to do this if you hit (escape-key) (current buffer index)? That's the way weechat works, and I keep expecting it to work in tmux as well :/
I think the idea is to be able to pound on whatever the defined escape key is to be able to toggle buffers, not that's he unable to find a command to switch to the next window.
Per your query: ctrl+a ctrl+a is how I switch between two windows (tmux calls them windows, they're basically tabs). If you want to switch between two panes (divisions inside a window, the equivalent of splitting the screen in a regular editor or visible buffers in vim/emacs), use ctrl-a o. I also have these bindings in my tmux conf for moving between panes painlessly:
# use hjkl for moving
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
This isn't very useful if what you want to run in your terminal buffer needs to constantly update its screen while you're working in a different buffer (e.g. irc, tailing log files, etc)
Umm.. why is it not useful? Emacs will allow multiple buffers to update at once, and you can work in a third while watching them... That's kind of the idea.
I've never been able to get it to deal well with vast amounts of output well. Constant overwriting issues etc. Definitely prefer to use tmux + emacs considering the huge amount of stuff i end up throwing at my term.
I stole this (possibly from Steve Yegge or another source) long ago to somewhat automate the process of renaming terminal buffers:
(global-set-key (kbd "<f2>") 'visit-ansi-term)
;; Terminal awesomeness
(require 'term)
(defun visit-ansi-term ()
"If the current buffer is:
1) a running ansi-term named *ansi-term*, rename it.
2) a stopped ansi-term, kill it and create a new one.
3) a non ansi-term, go to an already running ansi-term
or start a new one while killing a defunt one"
(interactive)
(let ((is-term (string= "term-mode" major-mode))
(is-running (term-check-proc (buffer-name)))
(term-cmd "/usr/local/bin/zsh")
(anon-term (get-buffer "*ansi-term*")))
(if is-term
(if is-running
(if (string= "*ansi-term*" (buffer-name))
(call-interactively 'rename-buffer)
(if anon-term
(switch-to-buffer "*ansi-term*")
(ansi-term term-cmd)))
(kill-buffer (buffer-name))
(ansi-term term-cmd))
(if anon-term
(if (term-check-proc "*ansi-term*")
(switch-to-buffer "*ansi-term*")
(kill-buffer "*ansi-term*")
(ansi-term term-cmd))
(ansi-term term-cmd)))))
Hey, I found that code hard to follow, with the if-then-elses nested 4 deep. A refactor, pretty much untested since I don't use ansi-term:
(defun visit-ansi-term ()
"If the current buffer is:
1) a running ansi-term named *ansi-term*, rename it.
2) a stopped ansi-term, kill it and create a new one.
3) a non ansi-term, go to an already running ansi-term
or start a new one while killing a defunct one."
(interactive)
(let ((is-term (string= "term-mode" major-mode))
(is-ansi-term (string= "*ansi-term*" (buffer-name)))
(is-running (term-check-proc (buffer-name)))
(anon-term (get-buffer "*ansi-term*")))
(cond
((and is-term is-running is-ansi-term)
(call-interactively 'rename-buffer))
((and anon-term (if is-term
(and is-running (not is-ansi-term))
(term-check-proc "*ansi-term*")))
(switch-to-buffer "*ansi-term*"))
(t
(cond ((and is-term (not is-running))
(kill-buffer (buffer-name)))
((and anon-term (not (term-check-proc "*ansi-term*")))
(kill-buffer "*ansi-term*")))
(ansi-term "/usr/local/bin/zsh")))))
One reason to run Emacs in tmux is if you work on remote machines over, e.g. ssh. Emacs in tmux (or screen) lets you detach, log out then log back in and re-attach to the remote session with Emacs still running. That's amazingly handy.
You still need a remote shell open if you want to run make, use SCM plugins, etc, so I've never found tramp that useful. If there's a clever solution for that I'd love to hear it.
eshell interfaces pretty well with tramp (well, not over FTP obviously, but ssh) so if you're editing a file over tramp and start eshell, it'll be in the directory of the file on the remote host. you can also use tramp-y paths in eshell:
I realize I'm a bit late to reply, but thanks for the tip. The biggest problem I had was with p4 mode (we use perforce at work) and rope-mode - I didn't really feel like hacking those to get it to work with tramp. And I can keep everything open across network disconnects with screen or tmux...
Well - it's my tool of choice for editing Makefiles. :) But that's all I use it for. My vim setup automatically hammers tabs to spaces, and make doesn't like that.
Shell users who use emacs mode (most ppl) may be annoyed by ctrl+a missing.
On most keyboards, you can enter it with control-space, which is very easy to type and rarely used for other purposes (though emacs uses for `set-mark-command`).
Control-] can also be a good choice (at least for US-style keyboards that don't require shift for the square brackets).
* Session choosing fixed to work with unattached sessions.
* New window options window-status-last-{attr,bg,fg} to denote the last
window which was active.
* Scrolling in copy-mode now scrolls the region without moving the mouse
cursor.
* run-shell learnt '-t' to specify the pane to use when displaying output.
* Support for middle-click pasting.
* choose-tree learns '-u' to start uncollapsed.
* select-window learnt '-T' to toggle to the last window if it's already
current.
* New session option 'assume-paste-time' for pasting text versus key-binding
actions.
* choose-* commands now work outside of an attached client.
* Aliases are now shown for list-commands command.
* Status learns about formats.
* Free-form options can be set with set-option if prepended with an '@'
sign.
* capture-pane learnt '-p' to send to stdout, and '-e' for capturing escape
sequences, and '-a' to capture the alternate screen, and '-P' to dump
pending output.
* Many new formats added (client_session, client_last_session, etc.)
* Control mode, which is a way for a client to send tmux commands.
Currently more useful to users of iterm2.
* resize-pane learnt '-x' and '-y' for absolute pane sizing.
* Config file loading now reports errors from all files which are loaded via
the 'source-file' command.
* 'copy-pipe' mode command to copy selection and pipe the selection to a
command.
* Panes can now emit focus notifications for certain applications
which use those.
* run-shell and if-shell now accept formats.
* resize-pane learnt '-Z' for zooming a pane temporarily.
* new-session learnt '-A' to make it behave like attach-session.
* set-option learnt '-o' to prevent setting an option which is already set.
* capture-pane and show-options learns '-q' to silence errors.
* New command 'wait-for' which blocks a client until woken up again.
* Resizing panes will now reflow the text inside them.
* Lots and lots of bug fixes, fixing memory-leaks, etc.
Two things I missed from screen last I tried tmux: an equivalent of 'screen -xRR' and an orthogonality between terminals and windows so that distinct terminals connected to one session can display different windows. Especially the latter of these is integral to my workflow.
For what it's worth, here is my carefully crafted ~/.tmux.conf file. I was used to screen, so I carried most of the keybindings along when I switched to tmux.
Author here. I know it's better for you to get the book cheaper, but PragProg gives authors 50% royalty on the sale of the book. If you buy it from pragprog, I get more in my pocket than if you buy from Amazon.
Either way, thanks for reading. I hope it's enjoyable. Some minor updates are coming to the book too.
Does this release have better performance than previous releases? I enjoy using tmux, but for some applications (i.e. with large amounts of text spewing to the console) it just hasn't (historically) performed as well as GNU screen.
Don't know if I'm the only one in this boat, but I often feel pretty conflicted about upgrading to a newer version of a tool where I have had a lot of configuration and shortcuts defined for ages. If any of them break, you'll have to go back and dig through the arcane tmux config file, figure out what changed.
the new choose-tree commmand is superb, for anyone who regularly uses tmux and already understands how great it is, you should consider upgrading for this alone..
with several sessions running on most of my machines, i frequently found myself `detaching` and `reattaching` to a different session... as the `choose-session` command gives you a full list of all the windows, which tends to obfuscate exactly what's going on, particularly if you have a bunch of sessions and windows..
however, the `choose-tree` gives you a session tree, which you can expand and easily identify... meaning that instead of sending `^a d`, followed by tmux attach sessionname you can comfortably do a `^a s` and get where you want to be (presuming you've remapped ^b to ^a)
also, you should be using the tmux buffers, `^a =`!
For the lulz I use neercs. It's the same as screen and tmux, except you get thumbnails of your panes in some kind of taskbar; and most importantly, you can switch between panes with a cube ascii animation, compiz style.
One thing that I really want is the ability to set different background colors for panes and windows. Sadly, it is a feature of a terminal app, not tmux. One can only imagine tmux would integrate tightly with various terminal applications to accomplish that.
If you are moving from screen to tmux, it's very easy to configure tmux to behave like screen. Also, for split panes, I like vim bindings('C-a l' for left pane, 'C-a r' for right pane, 'C-a <' for resize pane...). I have bindings for copying tmux buffer to and from clipboard(needs xclip).
Changelog: http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/CHANG...
Finally! I did not expect this feature, I thought the author was opposed to it. It is the one thing I have missed from screen (and part of the reason why I originally started using screen, since xterm does not reflow on resize either).
My favorite "resize-pane learnt '-Z' for zooming a pane temporarily."
"ctrl-[prefix] z" toggles zooming in on a pane now, this is awesome!!!
Anybody know if it's possible to move between terminal windows (panes in tmux lingo) "clockwise" and "anti-clockwise"?
Ctrl+b and then arrow keys will get you switching in all directions.
AFAIK there are tmux 'windows' which are like tabs and 'panes' which are vertical and horizontal splits in 1 tmux window
but assuming you mean 'panes', it seems you can:
Ctrl-b o
to move around the current window's panes clockwise. Although I prefer inputing a given direction like the other replier suggested with arrow keys.
For me moving between windows and panes is something that I do a lot. So much so that I removed the need to use the 'tmux prefix' to do so. In my ~/.tmux.conf I have for window and pane switching:
# set pane switching with <alt>{U, E, N, I} for up, down, left, right and respectively without needing prefix
bind -n M-N select-pane -L
bind -n M-I select-pane -R
bind -n M-U select-pane -U
bind -n M-E select-pane -D
# set window switching without needing prefix
bind -n M-a select-window -t :1
bind -n M-r select-window -t :2
bind -n M-s select-window -t :3
bind -n M-t select-window -t :4
bind -n M-d select-window -t :5
bind -n M-h select-window -t :6
You can just replace the keybindings I chose like M-a (alt-a) to something that works for you. If you want to keep using a prefix (incase you are worried the keybindings will clash with other program/system bindings), remove the '-n' flag. Hope that helps.
If it doesn't here is a tutorial I found from a google search: http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multip...
and IMO a really good book on Tmux if you decide to dive in more: http://www.amazon.com/tmux-Productive-Mouse-Free-Development...
Thanks. Yes, I meant panes.
I also did the thing to get rid of the tmux prefix for pane switching. But since I don't use the function keys, I mapped keys F1 through F9 to various tmux functions. F1 = next pane, F2 = prev pane. One less key to press. :)
cool! Hehe, ya, one less key to press FTW! :D
I use byobu http://byobu.co/
It binds the function keys which makes life so much easier. F2 starts new window, F3 and F4 rotate back and forwards. It also has a pretty neat status line.
What is the simplest way to install tmux 1.8 on Ubuntu 12.04?? Running `sudo apt-get install tmux` puts tmux 1.6 on my system...
Until it is packaged, it is fairly easy to build yourself. You just need libevent and ncurses.
Well the easiest way is either to wait for it to appear in the repos or wait for someone to package it and put it into a PPA. However, it doesn't have that many dependencies, so building it yourself is another not too stressful option.
I wouldn't suggest a questionable .deb somewhere...so you best just download source and ./configure then make then make install as described in the README: http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/READM....
You might need: 'apt-get install libevent-dev' as a prerequisite.
A simple `tar -xvf` can replace the separate `gunzip` and `tar` processes.
Do you mean `tar -xzvf`?
Yes, formally. You don't have to specify -z in GNU tar today, you can just say -x and it'll add -z or -j for you -- it figures out on the fly if the archive's been compressed and how. Very convenient.
You can also leave off the dash: `tar xvf`
And you may skip verbose too: `tar xf`
You can bypass writing the archive to disk, as well:
Shouldn't you be using checkinstall instead of 'make install' to make removal of the package easier in the future?
Not if you do local installs. You can remove the package simply by:
thanks @pkrumins - the download/compile/install cycle took about 30 seconds - the compiled executable seems to work perfectly.
instead of make install, consider checkinstall or fpm so that you are properly integrated into ubuntu's native package manager (dpkg). Doing so will save you headaches when you want to uninstall tmux or upgrade later.
Any PPAs?
I continue to be amazed by the people who install "random binaries" via PPA.
I guess I assume that if you want cutting-edge packages you'll use a cutting-edge release/distribution. If you don't, and you want something more recent then it seems to make sense to make your own packages, or install locally via gnu-stow, or similar.
Debian/Ubuntu packaging is far too difficult and thus creates bad incentives for people to install software from untrusted sources.
Should i finally switch from screens to tmux?
You should have switched a long time ago, but now is as good a time as any :P
You're going to open a big can of worms with that one ;). Tmux has quite a few more features than Screen, with Screen having a few features that are useful in edge cases[1]. It's hard to argue with tmux having bindings for vi/Emacs, as well.
If you're on a mac and use iTerm2, using tmux is somewhat of a no-brainer, thanks to the integration between tmux and iTerm2[2].
1: http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/FAQ 2: https://code.google.com/p/iterm2/wiki/TmuxIntegration
With reflowing text added to tmux, and giving that "Lots and lots of bug fixes, fixing memory-leaks, etc." the benefit of the doubt, then I would say that unless you have a specific use case of screen (and if you do, you know it) then you should be using tmux.
I've loved tmux since I switched a couple of years ago. Try it out for a few weeks. I think you'll like it better than screen.
I switched from screen to tmux to screen back again.
tmux seemed slower while switching windows, plus I like the simplicity of screen.
I was a heavy screen user for years, and 'simple' is not what I would use to describe screen.
Using tmux 1.8 and switching between windows is super fast.
After mastering screen, I switched to tmux. It's a lot easier to configure. It's also a lot nicer to split panes etc...
Definitely recommend the switch. You might be dreading it, but two days into tmux you won't regret it. It took many weeks trying to convince myself screen is better until I actually tried tmux out.
Yes, you definitely should, just make sure to plop this into your .tmux.conf
No, don't. C-b is a much better shortcut than C-a.
I agree, am i the only one using C-a in bash?
Perhaps a nice C-f then?
actually i'm using M+n (M=alt, n=number) to switch windows and i use M+[hjkl] to switch to left right top down window
I recommend the backtick: `
The only two pains that come with it are a) having to type `` to get a single `, and b) pasting anything containing a backtick behaves as if you'd typed it out.
I unbind M-Space from my window manager and use that for my prefix as well as for jumping to last window.
Tmux + Vim = Pure Awesome.
I use vim-slime[1] to send strings to other panes in tmux. I never type anything directly into a REPL. I just send my code from Vim to it. It's amazing with lisp or python. (A little less amazing with php, as the php repl IS AWEFUL)
[1] https://github.com/jpalardy/vim-slime
I totally agree. Plus, I use tmux + top, tmux + watch at work to get a quick idea on how my running experiments are going. It's really effective.
Ruby users may also be interested in adding pry to that setup: http://www.alanmacdougall.com/blog/2012/03/27/using-vim-slim... (disclosure: my own blog)
I love web pages like this. The top of it reads:
"tmux is a terminal multiplexer"
"What is a terminal multiplexer? It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal. And do a lot more. See the manual."
That's awesome. So many times someone posts on HN "CaffBook.ly.errr 0.98 now released" and I have no idea what it is or why I would want it.
I appreciated it too. I've heard tmux mentioned plenty of times but never with a mention of what it is/does. That one line did it.
After years of using screen i switched to tmux.. i'm sure i'm not even using a 5th of the functionality but i love it.
What are the primary advantages that tmux has over GNU screen that you found ?
I'm also wondering about this. I've been using screen for almost 20 years, and wonder if there's a compelling reason to switch.
Take a look here: http://unix.stackexchange.com/questions/549/tmux-vs-gnu-scre...
Some of it is arguable, but for me one of the greatest benefits is how tmux will auto-resize to the smallest terminal connected, making it useful for screen sharing or when connecting to an existing session from a mobile device.
For me, tmux has saner options and more mnemonic default keyboard shortcuts, that do not interfere with default bash shortcuts (Ctrl-A is goto-home-of-line in bash/emacs, but it is hijacked by screen by default as its escape sequence; tmux uses Ctrl-B for the same by default, which in the emacs bindings means go-back-a-character, and I do not use much, and is less likely to hit by accident).
I want to like tmux, I really do, but my main gripes are scrolling in panes with the scroll wheel and selecting / copy/pasting text. iTerm (osx) or Terminator (linux) handle that much better, although I admit they can't really be compared technology-wise.
Alternatively, I never figured out how to select / copy text just as fast in tmux / vim / etc as with the mouse.
tmux has mouse mode to enable scrolling/clicking.
This appears to be a helpful article: http://tangledhelix.com/blog/2012/07/16/tmux-and-mouse-mode/
Add these to your ~/.tmux.conf
Then you can scroll in panes, but also select like normal by holding alt/option.
I also hated tmux mouse wheel scrolling.
But tmux 1.8 mouse wheel scrolling seems much improved over tmux 1.6 - to the point that it looks quite usable.
Use iTerm2. One of the new features of tmux is
With this, if you connect to tmux via iTerm2, you can get it to pop up a window with tabs for each shell in the tmux session. History via the mouse wheel is native, changing tabs is native, new tab is native. Essentially you don't need to know any of the tmux commands at all unless you connect from a terminal program that doesn't know the protocol.
tmux status bars are customizable(no surprises there I guess) and the powerline is one of the nicer status bar arrangements - https://github.com/erikw/tmux-powerline
Is there any compelling reason to use tmux if you're already using a tiling window manager?
Persistent sessions is a nice feature.
when you're using ssh/mosh
Detached sessions on remote systems.
If that is the only reason, one could just use dtach instead.
http://dtach.sourceforge.net/
i've switched from tmux to screen to byobu ( which is a wrapper for screen ) because of its simplicity. screen also has very little problems, with tmux i always had time costly issues.
If you like tmux, also check out teamocil (https://github.com/remiprev/teamocil) to really enhance your use. It enables you to define tmux sessions via YAML, which is great for programmatically setting up a complex dev session. Mine, for example, fires up six panes in my preferred layout, and starts up a particular part of our project in each pane.
Ah, that looks excellent for more complicated setups. I've been using the slightly simpler tmuxinator.
https://github.com/aziz/tmuxinator
I used to use tmuxinator, but it's pretty much abandoned. There are pull requests that are over a year old. On the other hand, I submitted a pull request to teamocil and it was merged the same day.
I'll actually help maintain tmuxinator now. :) The project is really awesome but the author doesn't have enough time for it, so he added me to the project a few days ago. I'll go through the pull requests soon.
That's good to hear. I always hate to see good projects die because their creators are super busy. Good luck with taking things over!
Upvote for the best named project I've ever seen.
There's no 'i' in Timocyl, at least not where you think!
Sorry, I'm a bit thick and don't get it.
It's a reference to a TV show called Arrested Development.
Thanks. I really needed that in my head.
Teamocil author here, glad you like it! :)
Hacker News, man. Everybody's on here.
Sometimes it feels like the Marshall McLuhan scene in Annie Hall.
http://www.youtube.com/watch?v=9wWUc8BZgWE
I only glanced it over, but I'm having a hard time seeing the advantage of this over shell scripts calling tmux commands.
You could achieve the same thing with shell scripts, but one of teamocil’s advantages is that it gives you the simplicity of YAML to build complex layouts.
It's definitely a well-done, and I'll be pointing new users of tmux at it. I would have been all over it if I would have seen it the first time I dove into tmux's man page way back when.
If I get a chance, I'll give a go at converting the scripts for some of the layouts I use all the time, and see if it sticks.
"simplicity of YAML"
Spoken like someone who's never actually looked into how complex YAML can be.
I don't see how someone could possibly write a tool like this without being aware of YAMLs potential complexity.
Well, I suppose it's possible, but it seems extremely unlikely.
These days it's very easy to use a simple api without knowing about the dragons lurking beneath the surface. Flip side of our "reusable components" holy grail.
I agree. It takes surprisingly few lines of code to make a nice wrapper with some shortcut aliases/functions to simplify the scripts. My whole tmux workflow is managed by about 30 lines of code to bootstrap by tmux session management: https://github.com/treyhunner/tmuxstart/blob/master/tmuxstar...
If you don't like the YAML format of teamocil or tmuxinator and just want to write shell scripts to do the same thing, check out tmuxstart: https://github.com/treyhunner/tmuxstart
I made it shortly after switching to tmux last year. I hope this kind of functionality will eventually be built-in to tmux.
Anyone know if it is possible to do single combination keybindings? Currently all of the keybindings are things like 'Ctrl+W L', whereas I'd like to do things like 'Command+L'?
If you use bind-key -n C-f some-tmux-command it'll bind directly to Contrl-f. The -n means no prefix. I don't know how you'd make tmux recognize the Mac's command key though.
I realise you can rebind them, but both screen and tmux do themselves a disservice by choosing binding keys which overlap with prominent keys in emacs and for users who use emacs mode in their shell.
First impressions count.
If you want to configure tmux to use just a backtick as the escape, create ~/.tmux.conf
When you need to type a backtick just press it twice.
For screen, I used to do this:
.. in ~/.screenrc, but I've just tried it and it seems that there's now no easy way to type a backtick when you need one.
Query: in screen I can switch between two buffers by doing ctrl+a, ctrl+a. This doesn't work in tmux. How do I configure this to work in tmux?
"Ctrl-b n" for next-window?
That's not quite what I'm after. I guess it's hard for non-screen people to know what I'm talking about from my vague description above :)
Here's a scenario to show what I mean: you're in buffer 5. You switch to buffer 2. Now if you do ctrl+a, ctrl+a, you leap back to buffer 5. And if you do it again, you go back to buffer 2. This is great when you're editing code in one session and running it in the other.
I use that screen behaviour for panes:
bind C-a last-pane
but last-window exists too.
awesome. I hadn't thought of that but it's much better. thank you.
I've now switched last-window to bind C-s last-window, because it's fast to tap out.
Is there a way to set it up to do this if you hit (escape-key) (current buffer index)? That's the way weechat works, and I keep expecting it to work in tmux as well :/
I think the idea is to be able to pound on whatever the defined escape key is to be able to toggle buffers, not that's he unable to find a command to switch to the next window.
Switch the C-a for whatever your bind-key is.
thank you sir! I am now entirely migrated to tmux. :)
Per your query: ctrl+a ctrl+a is how I switch between two windows (tmux calls them windows, they're basically tabs). If you want to switch between two panes (divisions inside a window, the equivalent of splitting the screen in a regular editor or visible buffers in vim/emacs), use ctrl-a o. I also have these bindings in my tmux conf for moving between panes painlessly:
Nice one. I've now also added resize variations of these.
I bind C-z as the escape character (in screen). It seems to serve me well :)
I use ` as the prefix, so you might take a look at my tmux.conf[1] if you want help transitioning.
[1] http://pastebin.com/g6frvnnr
Ditto; mine's at https://github.com/pavellishin/dotfiles/blob/master/.tmux.co...
a
Emacs users should be using Emacs as their terminal multiplexer...
Could you elaborate? I'd love to try that.
Just open several terminal buffers in Emacs.
This isn't very useful if what you want to run in your terminal buffer needs to constantly update its screen while you're working in a different buffer (e.g. irc, tailing log files, etc)
Umm.. why is it not useful? Emacs will allow multiple buffers to update at once, and you can work in a third while watching them... That's kind of the idea.
M+x ansi-term should do it. I'm not sure how well that scales to many terminals though. M+x term also works. There is also eshell.
ansi-term and term are massively buggy.
I've never been able to get it to deal well with vast amounts of output well. Constant overwriting issues etc. Definitely prefer to use tmux + emacs considering the huge amount of stuff i end up throwing at my term.
; Open a terminal
M-x ansi-term
; Rename the buffer (escaping shell mode first)
C-c C-j M-x rename-buffer
; Shell responds to keyboard again
C-c C-k
; Split window in half horizontally
C-x 2
-----
I stole this (possibly from Steve Yegge or another source) long ago to somewhat automate the process of renaming terminal buffers:
Hey, I found that code hard to follow, with the if-then-elses nested 4 deep. A refactor, pretty much untested since I don't use ansi-term:
shell mode + emacs --daemon + emacsclient = all the multiplexing a growing engineer might need.
One reason to run Emacs in tmux is if you work on remote machines over, e.g. ssh. Emacs in tmux (or screen) lets you detach, log out then log back in and re-attach to the remote session with Emacs still running. That's amazingly handy.
Another option is tramp[1], which lets you open files remotely (generally via ssh/scp). Not the same thing, but often accomplishes the same goal.
[1] http://www.gnu.org/software/tramp/#Top
You still need a remote shell open if you want to run make, use SCM plugins, etc, so I've never found tramp that useful. If there's a clever solution for that I'd love to hear it.
eshell interfaces pretty well with tramp (well, not over FTP obviously, but ssh) so if you're editing a file over tramp and start eshell, it'll be in the directory of the file on the remote host. you can also use tramp-y paths in eshell:
cd /user@host:/home/user/
I realize I'm a bit late to reply, but thanks for the tip. The biggest problem I had was with p4 mode (we use perforce at work) and rope-mode - I didn't really feel like hacking those to get it to work with tramp. And I can keep everything open across network disconnects with screen or tmux...
Actually, make works in tramp by default if you use 'M-x compile' and friends.
Emacs-server does the same thing.
C-h f server-start
Well - it's my tool of choice for editing Makefiles. :) But that's all I use it for. My vim setup automatically hammers tabs to spaces, and make doesn't like that.
Shell users who use emacs mode (most ppl) may be annoyed by ctrl+a missing.
The following line in your vimrc will make vim not expand tabs for every file named "Makefile".
Wow - this thread is full of good advice. I have not touched my dot files in about four years, and today they're all getting an upgrade. Thanks!
At least in my vim, Makefiles are automatically set to noexpandtab even-though I have it set to automatically expand tabs for everything else.
If ctrl-a is your escape key then just do this:
if you use the command frequently enough, it might be worthwhile binding `^a a` and `^a^a`, similar to the tactic of binding F1 to <esc> in vim
I use the null character in GNU screen:
On most keyboards, you can enter it with control-space, which is very easy to type and rarely used for other purposes (though emacs uses for `set-mark-command`).
Control-] can also be a good choice (at least for US-style keyboards that don't require shift for the square brackets).
i suggest new commer give byobu a try, a wrapper of tmux.
its actually a wrapper for screen as also for tmux, the standard ubuntu package uses screen.
byobu is really recommended because its simple to use yet powerfull.
http://en.wikipedia.org/wiki/Byobu_(software)
Incompatible Changes ====================
* layout redo/undo has been removed.
Normal Changes ==============
* Add halfpage up/down bindings to copy mode.
* Session choosing fixed to work with unattached sessions.
* New window options window-status-last-{attr,bg,fg} to denote the last window which was active.
* Scrolling in copy-mode now scrolls the region without moving the mouse cursor.
* run-shell learnt '-t' to specify the pane to use when displaying output.
* Support for middle-click pasting.
* choose-tree learns '-u' to start uncollapsed.
* select-window learnt '-T' to toggle to the last window if it's already current.
* New session option 'assume-paste-time' for pasting text versus key-binding actions.
* choose-* commands now work outside of an attached client.
* Aliases are now shown for list-commands command.
* Status learns about formats.
* Free-form options can be set with set-option if prepended with an '@' sign.
* capture-pane learnt '-p' to send to stdout, and '-e' for capturing escape sequences, and '-a' to capture the alternate screen, and '-P' to dump pending output.
* Many new formats added (client_session, client_last_session, etc.)
* Control mode, which is a way for a client to send tmux commands. Currently more useful to users of iterm2.
* resize-pane learnt '-x' and '-y' for absolute pane sizing.
* Config file loading now reports errors from all files which are loaded via the 'source-file' command.
* 'copy-pipe' mode command to copy selection and pipe the selection to a command.
* Panes can now emit focus notifications for certain applications which use those.
* run-shell and if-shell now accept formats.
* resize-pane learnt '-Z' for zooming a pane temporarily.
* new-session learnt '-A' to make it behave like attach-session.
* set-option learnt '-o' to prevent setting an option which is already set.
* capture-pane and show-options learns '-q' to silence errors.
* New command 'wait-for' which blocks a client until woken up again.
* Resizing panes will now reflow the text inside them.
* Lots and lots of bug fixes, fixing memory-leaks, etc.
* Various manpage improvements.
This is all I needed to know to upgrade.
Two things I missed from screen last I tried tmux: an equivalent of 'screen -xRR' and an orthogonality between terminals and windows so that distinct terminals connected to one session can display different windows. Especially the latter of these is integral to my workflow.
tmux has been a great recent upgrade for me -- switched from a bunch of nested screens. really highly recommended.
http://www.tenshu.net/p/terminator.html kinda like this...
I use that one, I love it!
... Except the splits are inside the terminal session, so if you connect from another machine, you'll have access to all your panes
With terminator, you can have a windowing editor (vim) inside a windowing session manager (tmux) inside a windowing terminal (terminator).
Inception!
... inside a window manager (compiz) inside a nested x session (Xnest) inside a virtual machine (VirtualBox) inside a chroot.
Here [0] is a nice introduction to the newly introduced zoomed panes feature in tmux 1.8 by Tom Ryder.
[0] http://blog.sanctum.geek.nz/zooming-tmux-panes/
neat. this was the one feature i missed from xmonad!
Changelog:
http://sourceforge.net/p/tmux/tmux-code/ci/1b083aa0fd2d8ac00...
For what it's worth, here is my carefully crafted ~/.tmux.conf file. I was used to screen, so I carried most of the keybindings along when I switched to tmux.
https://github.com/ludwig/dotfiles/blob/master/tmux.conf
Does anyone know where to find a good introduction to tmux?
I attempted to start using it a couple of weekends ago but wasn't able to find any good documentation with my google-fu.
It costs $ but I really liked this pragprog book:
http://pragprog.com/book/bhtmux/tmux
Really good introduction, and the included config file is a good start.
And the book is $7.20 on Amazon for the Kindle, FYI. I just bought it (versus $14something @ pragprog)
Author here. I know it's better for you to get the book cheaper, but PragProg gives authors 50% royalty on the sale of the book. If you buy it from pragprog, I get more in my pocket than if you buy from Amazon.
Either way, thanks for reading. I hope it's enjoyable. Some minor updates are coming to the book too.
Glad you liked the book. I'm going to rolling out some minor changes in a couple days just to keep it updated with 1.8.
There's this: http://pragprog.com/book/bhtmux/tmux
To install/update on a mac, install Homebrew[1] and run `brew install tmux`.
1. http://mxcl.github.com/homebrew/
Does this release have better performance than previous releases? I enjoy using tmux, but for some applications (i.e. with large amounts of text spewing to the console) it just hasn't (historically) performed as well as GNU screen.
Don't know if I'm the only one in this boat, but I often feel pretty conflicted about upgrading to a newer version of a tool where I have had a lot of configuration and shortcuts defined for ages. If any of them break, you'll have to go back and dig through the arcane tmux config file, figure out what changed.
the new choose-tree commmand is superb, for anyone who regularly uses tmux and already understands how great it is, you should consider upgrading for this alone..
with several sessions running on most of my machines, i frequently found myself `detaching` and `reattaching` to a different session... as the `choose-session` command gives you a full list of all the windows, which tends to obfuscate exactly what's going on, particularly if you have a bunch of sessions and windows..
however, the `choose-tree` gives you a session tree, which you can expand and easily identify... meaning that instead of sending `^a d`, followed by tmux attach sessionname you can comfortably do a `^a s` and get where you want to be (presuming you've remapped ^b to ^a)
also, you should be using the tmux buffers, `^a =`!
For the lulz I use neercs. It's the same as screen and tmux, except you get thumbnails of your panes in some kind of taskbar; and most importantly, you can switch between panes with a cube ascii animation, compiz style.
http://caca.zoy.org/wiki/neercs
One thing that I really want is the ability to set different background colors for panes and windows. Sadly, it is a feature of a terminal app, not tmux. One can only imagine tmux would integrate tightly with various terminal applications to accomplish that.
If you are moving from screen to tmux, it's very easy to configure tmux to behave like screen. Also, for split panes, I like vim bindings('C-a l' for left pane, 'C-a r' for right pane, 'C-a <' for resize pane...). I have bindings for copying tmux buffer to and from clipboard(needs xclip).
https://gist.github.com/rahulkmr/5275679
id love zmodem support... but I'm probably the only one that uses it
Yes, that† and the possibility to directly connect to a serial port (like screen does). Would be a huge time-saver for the embedded folks.
†) or rather not builtin zmodem-support but generic "run this program with stdin/stdout connected directly to the device" like cu's ~+ escape.
pracically - how is it different form screen ?
'copy-pipe' mode command to copy selection and pipe the selection to a command.
This is exactly the functionality I was looking for back when it didn't exist. It wasn't immediately obvious how to use this, but here's how:
bind-key -t vi-copy 'y' copy-pipe "redis-cli -x set status"
set-option -g status-right '#(redis-cli --raw get status)'
And now I have a message I just copied to redis in my tmux status bar. I'm planning on doing this with clipboard text next.