I discovered i3 and the concept of tiling window managers a few years ago and have never looked back. A new terminal or browser window is always a keystroke away, as is swapping between "pages" of windows. It's all navigable completely by keyboard, so my vim/i3/dmenu editing environment has me very rarely touching the mouse. As an added bonus I get to use every part of the screen by default. No wasted space.
It's also pretty trivial to get some nice window arrangements so that I can quickly move to relevant parts of the code for whatever I'm working on.
I guess the major trade-off is that there aren't any menus for accessing functionality, but I personally consider that a win because I end up being forced to learn how to manage everything at the lowest config level, usually editing text files. This makes it vastly easier to script things when I realize I've been making the same changes over and over.
So if you like tmux and you're on Linux, I'd strongly recommend giving i3, awesome, or some other TWM a try.
I think you might be missing half of what tmux does. The tiling/multiplexing part is one half. The other half is the fact that it spawns a session that can run persistently in the background and which you can connect to from anywhere. You can also disconnect, let it sit there for a week, come back and it'll still be there exactly as you left it.
I use tmux as my primary "IDE", and it's absolutely indispensable being able to connect to my tmux session from any computer anywhere. I actually run tmux on one remote machine, and from my tmux session I ssh to 15+ other machines. I also use it as a tiling window manager, and I make full use of that aspect of it by generally maximizing my terminal so that it fills up a standard 27" 1440p monitor. If I'm working from a small laptop, it's a little less ideal, but all I have to do is select the right window and then use tmux's built-in zoom feature to maximize that one window. It works beautifully overall.
i3 is fantastic, but it can't replace tmux if tmux is being used to the full extent of its capabilities.
Yeah, tmux has two functions, and that's my (and others') problem with it. Instead of doing one thing well, it does two things poorly. It's not a very good window manager; when you use tmux you can't easily put a graphical window between two terminal screens. Even as a text-mode-only window manager it's lacking. It has poor mouse support, and every command you send to it has to first be announced with a prefix keystroke.
It's also not very good at keeping programs running. It can't survive a reboot, for example. It's possible to do that, and there's stable software that does it. Generally any program that can handle a suspend and resume can handle being persisted across reboots.
Not that I have a great suggestion for alternatives — I'm not really in the market right now. I use i3 for window management (not 100% satisfied, but it's definitely high quality software). I don't often run long-lived processes in ssh sessions these days. When I do, I use tmux, which is fine, I guess, if I don't have to do it often.
> Instead of doing one thing well, it does two things poorly.
It really doesn't. I think you just wanted something to say.
> It's not a very good window manager; when you use tmux you can't easily put a graphical window between two terminal screens
I think wanting to do that is your problem. I appreciate you may have your own insane use case, but mixing x/ptty makes no sense. Try just using your WM to switch to it.
> It's also not very good at keeping programs running. It can't survive a reboot, for example. It's possible to do that, and there's stable software that does it.
What are you even talking about? How is it supposed to know what your running and why you want to keep it running? Do you want your operating system suspend? Do you want to use docker pause/unpause? Then do. You can even script this stuff, which a number have done.
If your workflow unique to you then don't blame a tool designed for a different workflow
> > Instead of doing one thing well, it does two things poorly.
> It really doesn't. I think you just wanted something to say.
I'd say it does at least three things: terminal multiplexing, session management and copy/paste.
I switched away from tmux a while ago and now use DVTM for multiplexing and dtach for session management. DVTM delegates copy/paste to an external editor, but I've not used that functionality.
> every command you send to it has to first be announced with a prefix keystroke.
That's not a bug - that's exactly how every container-style program should work. That way, whatever is running inside the container, talking to the container can never get in the way. It's probably the most frustrating thing about web browsers and most window managers.
I went to effort to make my current window manager work that way (after getting used to it in ratpoison and, of course, screen/tmux).
Well I can appreciate the idea, and there's no other solution that can handle all cases of multiple levels of nested applications that all have their own keybindings (like a web app inside of a web browser inside of a window manager). But in practice I find it to be a horrible experience to use. I used a typical hipster OS X + tmux + vim setup for over a year a while back, so I speak from experience.
Graphic software vendors have essentially all agreed to never use the super key (aka windows key aka command) in their default configuration, an artifact of the time when you couldn't rely on computers having a super key, and of Windows reserving the super key for itself. Most modern window managers only use keybindings that involve the super key. Or at least Gnome 3 does, kinda, except for alt-tab and a few other bindings. Anyway, my window manager config only uses keybindings involving the super key.
It's a much more pleasant window management experience.
But yeah, I don't think there's an alternative that tmux could have used (though mouse integration could alieviate a lot of pain). But that's in itself an argument in favor of not using tmux to manage windows.
You can configure prefix-less keybindings for tmux. It might not be a good idea to do globally unless you know that none of your terminal apps will depend on the same key, but having that in per-project (or per-language) configs might be ok.
I find mouse and clipboard support a bit annoying but there's been changes to that in recent versions of tmux and I haven't reviewed what they do yet.
I haven't got to that part quite yet, but I've been considering adding a few global key shortcuts that would route e.g. run/continue/next/step to my debugger window, regardless of which tmux window is active.
> Generally any program that can handle a suspend and resume can handle being persisted across reboots.
This is not the case for very many of my processes. Are you suggesting DMTCP or something? That won't work with most of the stuff I'm running in terminals.
Other people thought that way I believe, hence the existence of dtach and dvtm. The nice argument is that by decoupling the two functionalities, you get two very tiny binaries instead of one quite ~larger tmux.
Well, not to be too snarky but you _are_ running screen/tmux in a terminal window.
And I hope I'm not the only person who considers having to move my hand off the keyboard and onto the mouse a UX bug.
every command you send to it has to first be announced
with a prefix keystroke
A friend of mine revolutionized my life when he showed me how he'd remapped GNU screen's command key from Control-A to backquote (`). Using screen went from being moderately annoying---especially to a die-hard Emacs user like myself---to being an essential part of every Unix/Linux server install I have done since. To be honest I don't understand why screen and tmux don't default to backquote instead of Control-A/Control-B, but maybe that's just the twenty-plus years of Unix-induced brain damage talking. :)
Probably because backquote is very often used by many people. In particular, people like myself who do a lot of Lisp programming. Outside Lisp, backquote is also used in sh (unless you want to give yourself RSI by using $(...)).
And this is the problem in a nutshell, there really is no single keystroke that everybody can agree is the perfect one to use. You obviously don't use backquote much, so for you, thats the perfect one. For me, Control-W is pretty good, unless of course I have to run Emacs at which time it becomes a terrible choice.
I use backquote pretty heavily, but I find typing "``" to get a literal backquote in the terminal to be much easier (and less stressful on my hands on modern PC keyboards) than "C-a a" to get a literal Control-A. YMMV.
Yes, I noticed. I also noticed that it doesn't justify that assessment by anything more than referring to ` as "legacy".
I'm not sure how much trust I would put into shellcheck. Especially since it doesn't flag the common error of "export FOO=bar" (instead of "FOO=bar ; export FOO").
Agree 100%. And I wrote a book on tmux. I would love something like i3 on my Mac. I can't give up OSX because I need its accessibility features because I'm low vision.
But if you're on Linux and you're not using i3, gosh, you have to give it a try.
Have you looked into Amethyst[1]? It's a tiling window manager for OS X. It's based on xmonad, not i3, but simply having something that tiles my windows is amazing, especially on larger Thunderbolt displays.
OSX has an unbeatable ability to zoom the full screen without losing mouse focus. No other OS I've tried supports this. Windows Magnifier comes close but it doesn't let me set focus to follow the mouse and it's awkward.
I use the full screen zoom and run Windows apps in virtualization. That's how important it is to me.
Ubuntu tried to make this work with Compiz a few years ago, and it was terrible as well. Slow and jerky.
But this is an absolute necessity for a low vision user like me. Got a Mac for my dad and he also can't live without it now.
Hopefully with Wayland coming around, this will all be simpler. The reference Wayland compositor (Weston) has a built in fullscreen zoom feature which is basically identical to OS X's (hold down key, scroll).
In fact, the default implementation in Weston is, better in my opinion, and also enabled by default. Instead of having to go to the edge of the screen to move the region, it moves the region with the cursor in the same position relative to the screen as the region. Of course, for those with dyslexia or some other psychovisual disability; it may be worthwhile to have an option to go the OS X route.
Thanks for the input, I'll maybe put it on the GNOME bugzilla if it isn't already there. :-)
The OSX zoom has the option to follow the mouse and is what I use (and require) so I can track what I'm reading. It's not default, but it exists and works incredibly well even under heavy graphics use. Seeing something like that work well on something other than OSX would be great. But every other attempt has bee spotty at best.
I look forward to seeing this work, but I worry about the hardware requirements that will be imposed.
I have a 2007 white macbook that zooms flawlessly. If I need a high-end video card to zoom as smoothly it will be a problem.
For some information, it is unfailingly buttery smooth even on integrated graphics hardware from one generation before Intel HD graphics. I.e. a lenovo Core Duo machine from 2006 I dug out of my closet the other month. This is all probably thanks to Wayland being properly composited to begin with; they just need to scan out part of the final framebuffer texture.
KDE 4 and 5 have a magnifier that follows the mouse and has worked just fine in any situation I've thrown at it. It's enabled by default, but you do have to assign keyboard shortcuts to "Kwin zoom in/out/restore-to-actual-size".
I use full-screen zoom in Ubuntu (14.04) and Macintosh everyday. In Ubuntu I can alt-tab between apps and the zoomed window will follow me to the top-most application, not so on the Mac which will switch apps but leave me viewing the wrong portion of the screen. Both will follow the mouse equally well. On the other hand I prefer the Mac's ctrl-scroll-up/down to zoom-in/out. On Ubuntu I use a couple of key-combinations as I haven't figured out how to do it with the mouse. I guess I'm suggesting to give Ubuntu another chance.
I wonder if you know TouchZoomDesktop. While it focus on touch input, it can be used with mouse/keyboard as well and offers easy zooming of the whole screen. I use it in presentations. http://www.lovesummertrue.com/touchzoomdesktop/en-us/
You're book is great for getting up to speed with tmux basics. The intro to tmuxinator was also pretty helpful.
One of the bigger things I think people miss is copying text into and out of tmux panes, including to the clipboard. This saves me a lot of time switching between windows often, especially using the vi keybindings. Although one thing I wish tmux did better was handling things like dividers.
I thought the book was great. It's a quick read, but easily increased what I could do with tmux. I can't think of much more it really needs. Maybe cover stuff like if-shell? The true-color patch might also be worth mention.
FYI, there's a slight bug with the xclip copy binding, but it's pretty easily fixed (bind C-c run "/usr/bin/tmux save-buffer - | /usr/bin/xclip -i -sel clipboard >/dev/null").
Just using tmux to get more than one terminal was really only a fraction of the stuff I could use it for. My terminal launches in XMonad use tmux by default now.
As far as the copy stuff, I'm talking about pipe or line dividers in terminal apps (e.g. mutt, ncmpcpp, etc... If whatever I'm trying to copy covers more than one line, tmux will copy over the divider which is painful.
I've had success with kwm[0], it works more like bspwm than i3 but has been the best tiling experience I've found on OS X. (And has focus follows mouse!!!!)
I bought your book too, thanks for writing it! I found it helpful and it got me started scripting tmux sessions. I plan to try tmuxinator but haven't yet.
For some reason I've ended up using a combination of i3, tmux, and Emacs window splitting, all at the same time. So three different programs that do something like window management, each with its own set of behaviors and keystrokes. This sounds like it should be a nightmare, but it's actually not that bad.
Others have mentioned the additional benefits of tmux beyond window management, but I also find that, much as I like i3, it's actually pretty hard to quickly and intuitively create, manipulate and delete window splits. Ie, top-bottom, side-by-side, rotate splits, stuff like that. The containers thing just seems unweildy, and just getting windows into the right containers always feels like a fight. I used to use StumpWM, and while that had its own problems, you could bang things next to each other for a second without having to really think about it.
Part of it is probably that I end up very rarely needing top-level window splitting, so I never get used to the keybindings. Splitting in the terminal and in Emacs takes care of most of my needs; I want to see different programs side by side no more than once every few weeks.
PS: There's a program called Sway that's basically a Wayland fork of i3. I keep it updated on my machine, and every once in a while amuse myself by using `startsway' instead of `startx'. It's coming along nicely, and you get that nice feeling of being retro and advanced at the same time. http://swaywm.org/
> So three different programs that do something like window management, each with its own set of behaviors and keystrokes.
I've found this a bit painful too but it gets better if you configure your window management keys with similar bindings. But I still do find it a bit annoying to have three levels of windowing (vim, tmux, bspwm) when I'd be happy with just one.
Tiling is the least useful thing that tmux does. Event the name (tmux) implies that it's core competency is something else entirely -- multiple sessions, kept open, switching between them, persisting, etc.
Exactly this. I open tmux on remote connections, maybe to panel (Altho scrolling through output in tmux sucks), but definitely in case I lose my connection while running a longer process.
My other favorite use is screen sharing without screen sharing (2 people connecting to the same session), super helpful when taking control over screens share is too slow due to network lag.
I'd agree that tiling is the less useful function, but the name refers to the tiling. Tmux is short for Terminal Multiplexer, in other words, it's a program that turns one terminal into multiple terminals, by way of tiling.
you'll see "screen is a full-screen window manager that
multiplexes a physical terminal between several processes", describing a piece of software that - at that point - didn't do any splitting or tiling.
OK, I said "tiling" instead of "window management", I should have been more precise but instead opted to use the same language the parent used. Coldtea claimed that the name tmux was a reference to "multiple sessions, kept open, switching between them, persisting", which I interpret as all the non-window-manager functionality — the attach/detach ability that makes tmux attractive for use on remote machines where the connection might die and you don't want to lose your processes.
"Multiple sessions, switching between them" is multiplexing. "Kept open, persisting" is orthogonal, I agree. The parent said "tiling" and I assume they were referring to, well, tiling - putting multiple non-overlapping windows on the screen at the same time by dividing up the available space.
That definition doesn't apply any better to the attach/detach functionality of tmux than the window management functionality, so you're going to have to use a more flexible definition than that for the term to ever apply to tmux.
A USB hub multiplexes a USB port by making it so that multiple USB devices can be connected to the same port and all pretend that they're the only ones connected to it.
The Ogg container format multiplexes a bitstream so that multiple timecoded media streams can be streamed through the same data channel and pretend that they're the only things going through it.
An preemptive-multitasking OS kernel multiplexes the CPU so that multiple processes can run on the cpu and all pretend that they're the only ones on it
A terminal multiplexer multiplexes the terminal so that multiple processes can output to the terminal and all pretend that they're the only ones using it.
That describes the window management functions of tmux.
>That definition doesn't apply any better to the attach/detach functionality of tmux than the window management functionality
It does apply with 100% to what it's meant to be applied: multiplexing terminal IO.
It has nothing to do with "window management". In fact it could also offer no window management at all, except for switching between sessions, which is was what it did initially.
Multiplexing is a well known, precise term, and terminal multiplexing as a technique existed before both tmux and its introduction of tiling (e.g. screen).
If you're really looking to do something strange, you could ditch the mouse all togeter. That's what I've done on one of my laptops.
For some reason when i first set it up the touchpad didn't work, and need some driver or something. Instead of fixing it like a normal person, I said to me self "just go with it".
I found a browser (qutebrowser) that works by using just the keyboard, and use tmux/vim and other terminal apps for everything else. The scrolling in the browser highlighted weird stuff (since the mouse cursor was always in the middle of the screen), but once I found a way to set the cursor to the top-left of the screen when X starts (a command in .xinitrc), no more issue.
I still have a minor issue every once and while. Sometimes i'll browse around and see a code snippit, or just some text I'd like to copy-paste, or a link with a url I'd like to copy and I'm not sure how. That's really been my only downside of going mouse-free.
This very useful info for me as well. I have periodic pains in my neck when using mouse for too much. I have been switching hands. But still. I much prefer emacs-like interface where I can operate with keyboard only.
And I like shells because I can connect from anywhere to the server where I do most dev and testing.
However, I recently started doing android development and and I am forced to leave my emacs and shells.
One reason is the running the emulator. It cannot run on remote x window sessions and I have to use mouse to access it.
The other reason is AndroidStudio. Although I use emacs with flymaker, as a newcomer to Android -- I find Android Studio's tools to do code refactoring, on the fly suggestions, detection of new versions of updates, very useful.
how do you copy from a terminal buffer to another window?
tmux allows selection without a mouse, but I agree with others that tmux tries to do too many things at the same time and I would therefore like to have a simple solution for this.
Since I can move the mouse I have no need for the pointer lock but I use unclutter a small utility that makes the mouse disappear when it's not used for a time.
For copying, qutebrowser has caret mode (I believe the hotkey is 'V') that lets you move the pointer with the keyboard and visually select and copy text as you would with vim.
Copying url's is done with the 'y' hotkey and a terminal emulator I use (termite) has a hotkey for finding and opening urls from the terminal.
I use tmux as a persistent terminal multiplexor on a higher-than-preferred latency connection. I'm worried that i3 over VNC would be even slower, but I'm willing to give it a shot. Do you use i3 on a local or a remote Linux machine?
It depends on whether or not vnc is bandwidth limited on your link. A high bandwidth, high-latency connection shouldn't feel significanlty different over vnc or a terminal, but if your high-latency is due to being bandwith-limited, vnc will be much worse.
i3 is your tiled window manager. You just open your terminal and connect on ssh as usual. i3 wouldn't have anything to do with your connection to the ssh session.
I share the same feeling (as for the splitting feature alone). I also love the minimalism and the fact that there is no screen estate waste(1 windows takes 100% of the screen, 2 takes 50% each, etc...).
Since I switched to i3 I completely stopped to use tmux.
/r/unixporn is full of i3 screenshot and config to learn from i would encourage new users to look at it.
> So if you like tmux and you're on Linux, I'd strongly recommend giving i3, awesome, or some other TWM a try.
I've heard great things about i3 & awesome, but haven't used them myself. I've been using stumpwm for several years now, and I just love it. There's nothing like being able to connect to one's WM in a SLIME session and recompile portions of it while it's running!
I use i3 for tiling graphical windows, but I use tmux for tiling and multiplexing terminal panes. The reason I prefer using tmux for terminal stuff is so that I only ever need one terminal window open, I can use the same tool when connected to remote machines with only one connection, etc.
The benefit of i3, though, is that a terminal is just another window, and the direct navigation happens between windows. I can jump directly from a terminal to a browser or IDE because the construct is the same for all of them.
What about saving sessions? With Tmux/Screen, when I close the window, the session can be saved, meaning when I come back tomorrow, everything is right where I left it.
It's also pretty trivial to get some nice window arrangements so that I can quickly move to relevant parts of the code for whatever I'm working on.
I guess the major trade-off is that there aren't any menus for accessing functionality, but I personally consider that a win because I end up being forced to learn how to manage everything at the lowest config level, usually editing text files. This makes it vastly easier to script things when I realize I've been making the same changes over and over.
So if you like tmux and you're on Linux, I'd strongly recommend giving i3, awesome, or some other TWM a try.