The best way I have found to use tmux is to unbind everything and set only the things I use for my workflow. Then the configuration (.tmux.conf) becomes the docs.
I was inspired by the "How to Configure tmux from scratch" post [1].
I came up with my use cases:
- I want to create sessions
- I want to open and close windows
- I want to create split panes
- I want to use vim-style text select
- etc.
Then I made mappings for the things I care about for my workflow specifically.
Before this, I would accidentally hit a keybinding while doing something else and not know how I got to that state, taking me out of flow to troubleshoot.
Afterwards, only the keybindings I have defined take action.
Now tmux fits like a glove. Because tmux is so stable, I haven't had to touch my config in years. It's worth the one time effort.
I haven't strayed from tmux default configuration that much over the years (and these days, I don't even bother to alter it). The reason is that it's just another set of keybinding shortcuts to memorize, and if I forget some, the help screen is clone. But the few that are ingrained are guaranted to work everywhere.
> Before this, I would accidentally hit a keybinding while doing something else and not know how I got to that state, taking me out of flow to troubleshoot.
I used to accidentally background my tmux frequently and the first couple times made my heart sink in that “did I save??” way lol, though these days I’ve largely stoped using it since splits feel smoother in Kitty and I don’t do any remote sessions.
"When I first started using tmux, I felt overwhelmed by the very poor default UI that it offers and the amount of options and shortcuts that I needed to know to operate it well and be productive. It took me several tries before I started to feel more or less comfortable with it. One of the things that stood out to me right away was how dreadful UI looked. Not only it felt uninviting, but it almost felt “gatekeepy” - if you don’t know how to use it in this configuration, then might as well forget about it."
EPendragon elaborate on this. It seems like you understand the shell enough to use it productively and customize it to be how you like it. The screenshot this quote is talking about looks like a shell? In what way is it dreadful, and in what way do your customizations make it not dreadful?
For example, it seems like a valid criticism that shells are not very discoverable and a prompt and blinking cursor can be intimidating to a noob, and that surely applies to tmux as well. But then changing the shortcuts doesn't really address that, does it?
To me it seems your article is either saying, "tmux is a pig, and here's me putting some lipstick on it," :) or the problems are not insurmountable, and the solutions are nice but not life-changing.
It's great that you like it better now, and we're all having fun chatting around it about how we configure our tools here on the Hacker News :) But I don't see why it's "dreadful". It's just.. computers, no? Tmux seems no more gatekeepy than any other aspect of computers. And I say this as someone who stopped using tmux a few years ago after getting super annoyed with it.
The initial experience where I saw a lot of elements on the screen without knowing what's what was a lot. And sure enough - a lot of it had to do with just learning how it works and what's what. But in addition to the UI that is unintuitive for the beginner, most of the keybindings either didn't make sense or were not convenient (talking about prefix).
For example, splitting panes in my opinion are much better done with | and - symbols rather than " and %. I can see what they were going for with double quotes and the percent sign, but IMO vertical line and a hyphen make more sense. I do not need to be actively thinking about which one should I use for a vertical vs horizontal split.
There was some aspect of "putting a lipstick on it" - for sure. Making it more pleasant to look at didn't improve function - just looks. I just think making your tools look the way you like and enjoy them will create a more pleasant experience and help you learn the tool faster too.
The dreadfulness did come from not understanding it completely and being a noob early on. Fixing the style and function also put me into a process of being intentional about learning how the tool works and adjusting things that I didn't like.
And you're right - it is not more gatekeepy that other tools per se. I was simply describing my experience and what I ended doing about that.
Thanks! I'm glad I asked, because there does seem something here I can learn from. I care very much about what makes a power tool with a high ceiling gatekeepy.
What were the "lot of elements" in the screenshot? Ignoring shell stuff, is it the bar at the bottom? Is it the "[0]" and the "0:bash*"? The "Macbook-pro" might seem familiar to someone familiar to the shell, who is used to seeing it in the prompt of an uncustomized shell. The date and time likewise seem obvious what they mean. Am I missing anything?
I think the keybindings being non-mnemonic there's only so much you can do about. Vim's hjkl were mnemonic on the VT-100 terminal, but keybindings outlast mortal hardware. So the ability to rebind is in some ways the best you can get IMO.
Zooming out, the best power UI I've been able to come up with is a combination of a Wordstar-like always-on menu showing common keybindings, and a command palette. Here are a couple of UIs I've made, I'm curious what you think of them:
I have to admit I don't like customizing tools like tmux too much. Personally I prefer to just learn and live with the defaults. That mean losing out on some things, but I think it's a good trade off for having thing just work like you expect on random server you sign in to.
Especially something like keyboard shortcuts and leader keys doesn't make sense to change in my mind. It just confuses you when login in to a remote host.
I have thought about that. For this same reason I did not remap a lot of keys in nvim, because I still want to be able to use vim wherever I work if that is the only option.
However, I think that creating a simple git repository with rc files and configuration can be used to create a uniform experience across machines.
The git repo idea is fine for some machines, but when I log into a random customers server at 4:00AM to fix some issue that paged me, I'm not spending time cloning a repo to setup neither vim nor tmux, it just has to work.
Also the machine may not actually able to reach out onto the wider internet.
This exactly. While on the visual side I prettified it a bit over time, Initially I was really tempted to do some major keybind remapping, having used lots of GUI terminals like Terminator in parallel, especially the infuriating h/v splits that I still routinely confuse after years with tmux, but I stopped myself so as not to cripple myself when I log in to anything that has tmux running defaults - and I'm happy with this choice.
I love tmux! Using it as a tool suddenly enabled me to do so many things. Lately I've been using Zellij, which I'd massively recommend for anyone not wanting to do a load of customisation. It just works great out the box (but probably has less wiggle room to "make your own")
I feel that “make your own” has been the major driver behind looking into the configs myself. Learning other configs feels like a chore. I would rather learn and make it as I go. In the end I will have a sense of complete ownership. I will know what needs to change if I decide to change it. I think investing time into making your own wins in the long run.
I will definitely check it out. Thanks for the suggestion! What would you say is different between tmux and Zellij, and why did you start using the latter?
If you've used Neovim vs Helix, I'd say the comparison is pretty close.
Tmux is more customisable, but a lot messier out the box. It's much older so has picked up a little cruft along the way.
Zellij is newer so has the benefit of being a clearer implementation. But it's designed as an "out the bix" experience, not one you can customise to your hearts content.
Edit: if you did want to try out zellij, I should point out there's a "no install, try in shell" option on their website's main page which is a super quick way to get a taste!
I don’t know what it is about how my brain works, but I have absolutely no memory for keybinds (and envy those that do), so I love that it just lays them out in the UI.
Only customisation I make is to turn off the borders.
Would love if built a similar, visually guided, experience for nvim.
@HNModerators, I don't know why it was necessary to change the title of my post from "Customizing tmux and making it less dreadful" to "Customizing tmux". The point of the title was not the overview of all of the customization options, but the effort to make it more usable, convenient, and pleasant to use.
I have noticed that about an hour ago, so I don't think it was automatic. I guess I'm just curious why it was found to be against the guidelines or not representative of the topic in the post.
The article is focused on interactive use, but I would be interested to also hear from folks using tmux as a process manager / dashboard for server-type environments. I was pretty unenthused about this practice when I first encountered it, but it's grown on me as a way to quickly get a sense of state from onboard a running system without having to rely on off-board dashboard or log parsers / alert systems.
In particular, I'm curious about libtmux/tmuxp and how well it works to have a more declarative bringup than just a bash script launching things into the background and then attaching tmux windows to them.
And I guess the broader question of whether this approach is an evolutionary dead end— like does it just become a pile of hacks as one discovers the need for restart policies, backoffs, ordering, whatever other stuff that is built into a "normal" process manager like systemd or runit? If you do end up wanting to send process stdout/stderr elsewhere or do alerting, is that now annoying if those streams are "trapped" in tmux sessions vs being written into log files or the journal?
> I would be interested to also hear from folks using tmux as a process manager / dashboard for server-type environments
Sure! I use tmux on most of my OpenBSD systems and copy the same .tmux.conf file around, but rarely tweak it other than to set a hostname.
My status bar is at the top and looks approximately like this:
--~ msg auth pf hostname. Mon Aug 04 15:05
* The first two windows (--) are regular shells.
* The tilde window (~) is where I do stuff as root.
* The message window (msg) tails `/var/log/messages` and `/var/log/daemon`, or `journalctl -f` and `journalctl -k -f` on Linux.
* The auth window (auth) tails `/var/log/authlog` to monitor login attempts and usage of doas and sudo.
* The pf window (pf) runs a script to monitor the packet filter rules (pass, block, match).
* hostname is just the hostname. The period (.) means no mail, it turns to an exclaimation mark (!) when I have mail.
* Simple date/time.
This setup gives me quick access shells, important logs, mail status, date/time, and works the same on every server I manage. I add extra windows to tail other app logs as needed.
I’ve seen people use this approach (and screen too) but personally I hate it for anything other than services that are interactive but you want detachable. Eg long running installs.
All the other examples I’ve seen where people have used it as a shortcut for daemonizing a service, it’s felt like just as much effort as writing a systemd service file.
I guess I could forgive people more back in the days of sysv-style initd. Writing those shell scripts was seldom fun. But with systemd, it’s literally a 5 minute task. And I say that as someone who dislikes numerous decisions made regarding the approach systemd takes.
For daemonizing a single service, I agree it's silly. I think the argument becomes more complex when you have a whole group of services. The "proper" way for that involves a systemd unit for each process, and then if you want the dashboard experience you still have to launch all the panes and get each one tailing the respective unit journals.
It's tougher to make the case there that systemd units are "worth it", particularly given the other ergonomic benefits of a pure tmux solution, such as being able to ctrl-c a pane and trivially re-launch it.
And once you're launching services in a container, that's another world again, since systemd in that case is quite a bit worse and probably wants CAP_ADMIN.
I wrote a quick and dirty bash script that launches a tmux dashboard for a legacy linux server. The team has been happy with it. It does seem like an evolutionary dead end to be honest, but it was very quick to set up.
Note that the dashboard is read-only and mostly just shows journalctl for different units (we use systemd for process management). And we assume it's only used by a single user at once and everything is stopped on detach.
Here's a simplified sample of setting up a 3x2 layout with some placeholder content:
I've used tmux like that a bunch before discovering process-compose [1]. Still use tmux a lot with remote connections and booting up a few scripts in parallel is still easier with it, but for longer-serving setups p-c has helped a lot
I tend to use byobu as a wrapper around tmux wherever possible - this combination might have gotten the author close enough to where they wanted to be.
Well, they'd still need to bring their own ascii teacup.
I also am a fan, and find it much easier to successfully suggest byobu to others with its simple "F-key to action" mapping of common actions. I work with a bunch of non-developers, so the lower barrier to use is important :)
As someone who lives in terminals, iTerm2 may be the Killer App for Macbooks.
You see, it has Tmux Integration [1], which makes tmux windows and panes become native tabs and panes in iTerm, which means I don't need to use weird chords to manipulate tmux, but most importantly, most UX-ily, it has native scrollback. No need to escape into a weird secondary mode just to do the most basic thing that all graphical terminals are good for.
If you work with terminals on remote machines, you owe yourself to use tmux. If your client is a Mac(book), you owe yourself to use iTerm2.
The weird thing is that iTerm2 is the only Terminal Emulator to leverage Tmux's Control Channel mode, for the integration. For all the breadth of copycat terminal emulators on Linux, none of them perform this one killer feature.
Readit News
I was inspired by the "How to Configure tmux from scratch" post [1].
I came up with my use cases:
- I want to create sessions
- I want to open and close windows
- I want to create split panes
- I want to use vim-style text select
- etc.
Then I made mappings for the things I care about for my workflow specifically.
Before this, I would accidentally hit a keybinding while doing something else and not know how I got to that state, taking me out of flow to troubleshoot.
Afterwards, only the keybindings I have defined take action.
Now tmux fits like a glove. Because tmux is so stable, I haven't had to touch my config in years. It's worth the one time effort.
[1] https://ianthehenry.com/posts/how-to-configure-tmux/
I used to accidentally background my tmux frequently and the first couple times made my heart sink in that “did I save??” way lol, though these days I’ve largely stoped using it since splits feel smoother in Kitty and I don’t do any remote sessions.
Deleted Comment
EPendragon elaborate on this. It seems like you understand the shell enough to use it productively and customize it to be how you like it. The screenshot this quote is talking about looks like a shell? In what way is it dreadful, and in what way do your customizations make it not dreadful?
For example, it seems like a valid criticism that shells are not very discoverable and a prompt and blinking cursor can be intimidating to a noob, and that surely applies to tmux as well. But then changing the shortcuts doesn't really address that, does it?
To me it seems your article is either saying, "tmux is a pig, and here's me putting some lipstick on it," :) or the problems are not insurmountable, and the solutions are nice but not life-changing.
It's great that you like it better now, and we're all having fun chatting around it about how we configure our tools here on the Hacker News :) But I don't see why it's "dreadful". It's just.. computers, no? Tmux seems no more gatekeepy than any other aspect of computers. And I say this as someone who stopped using tmux a few years ago after getting super annoyed with it.
The initial experience where I saw a lot of elements on the screen without knowing what's what was a lot. And sure enough - a lot of it had to do with just learning how it works and what's what. But in addition to the UI that is unintuitive for the beginner, most of the keybindings either didn't make sense or were not convenient (talking about prefix).
For example, splitting panes in my opinion are much better done with | and - symbols rather than " and %. I can see what they were going for with double quotes and the percent sign, but IMO vertical line and a hyphen make more sense. I do not need to be actively thinking about which one should I use for a vertical vs horizontal split.
There was some aspect of "putting a lipstick on it" - for sure. Making it more pleasant to look at didn't improve function - just looks. I just think making your tools look the way you like and enjoy them will create a more pleasant experience and help you learn the tool faster too.
The dreadfulness did come from not understanding it completely and being a noob early on. Fixing the style and function also put me into a process of being intentional about learning how the tool works and adjusting things that I didn't like.
And you're right - it is not more gatekeepy that other tools per se. I was simply describing my experience and what I ended doing about that.
What were the "lot of elements" in the screenshot? Ignoring shell stuff, is it the bar at the bottom? Is it the "[0]" and the "0:bash*"? The "Macbook-pro" might seem familiar to someone familiar to the shell, who is used to seeing it in the prompt of an uncustomized shell. The date and time likewise seem obvious what they mean. Am I missing anything?
I think the keybindings being non-mnemonic there's only so much you can do about. Vim's hjkl were mnemonic on the VT-100 terminal, but keybindings outlast mortal hardware. So the ability to rebind is in some ways the best you can get IMO.
Zooming out, the best power UI I've been able to come up with is a combination of a Wordstar-like always-on menu showing common keybindings, and a command palette. Here are a couple of UIs I've made, I'm curious what you think of them:
https://merveilles.town/@akkartik/108766067153506592
https://github.com/akkartik/mu/blob/main/html/20210624-shell...
Especially something like keyboard shortcuts and leader keys doesn't make sense to change in my mind. It just confuses you when login in to a remote host.
However, I think that creating a simple git repository with rc files and configuration can be used to create a uniform experience across machines.
Also the machine may not actually able to reach out onto the wider internet.
https://zellij.dev/
Tmux is more customisable, but a lot messier out the box. It's much older so has picked up a little cruft along the way.
Zellij is newer so has the benefit of being a clearer implementation. But it's designed as an "out the bix" experience, not one you can customise to your hearts content.
Edit: if you did want to try out zellij, I should point out there's a "no install, try in shell" option on their website's main page which is a super quick way to get a taste!
I don’t know what it is about how my brain works, but I have absolutely no memory for keybinds (and envy those that do), so I love that it just lays them out in the UI.
Only customisation I make is to turn off the borders.
Would love if built a similar, visually guided, experience for nvim.
https://news.ycombinator.com/newsguidelines.html
In particular, I'm curious about libtmux/tmuxp and how well it works to have a more declarative bringup than just a bash script launching things into the background and then attaching tmux windows to them.
And I guess the broader question of whether this approach is an evolutionary dead end— like does it just become a pile of hacks as one discovers the need for restart policies, backoffs, ordering, whatever other stuff that is built into a "normal" process manager like systemd or runit? If you do end up wanting to send process stdout/stderr elsewhere or do alerting, is that now annoying if those streams are "trapped" in tmux sessions vs being written into log files or the journal?
Sure! I use tmux on most of my OpenBSD systems and copy the same .tmux.conf file around, but rarely tweak it other than to set a hostname.
My status bar is at the top and looks approximately like this:
* The first two windows (--) are regular shells.* The tilde window (~) is where I do stuff as root.
* The message window (msg) tails `/var/log/messages` and `/var/log/daemon`, or `journalctl -f` and `journalctl -k -f` on Linux.
* The auth window (auth) tails `/var/log/authlog` to monitor login attempts and usage of doas and sudo.
* The pf window (pf) runs a script to monitor the packet filter rules (pass, block, match).
* hostname is just the hostname. The period (.) means no mail, it turns to an exclaimation mark (!) when I have mail.
* Simple date/time.
This setup gives me quick access shells, important logs, mail status, date/time, and works the same on every server I manage. I add extra windows to tail other app logs as needed.
In case helpful: You can use `#h` in a status line string to get the hostname
All the other examples I’ve seen where people have used it as a shortcut for daemonizing a service, it’s felt like just as much effort as writing a systemd service file.
I guess I could forgive people more back in the days of sysv-style initd. Writing those shell scripts was seldom fun. But with systemd, it’s literally a 5 minute task. And I say that as someone who dislikes numerous decisions made regarding the approach systemd takes.
It's tougher to make the case there that systemd units are "worth it", particularly given the other ergonomic benefits of a pure tmux solution, such as being able to ctrl-c a pane and trivially re-launch it.
And once you're launching services in a container, that's another world again, since systemd in that case is quite a bit worse and probably wants CAP_ADMIN.
Note that the dashboard is read-only and mostly just shows journalctl for different units (we use systemd for process management). And we assume it's only used by a single user at once and everything is stopped on detach.
Here's a simplified sample of setting up a 3x2 layout with some placeholder content:
[1] https://github.com/F1bonacc1/process-compose
Well, they'd still need to bring their own ascii teacup.
https://www.byobu.org/
It's free https://iterm2.com/
As someone who lives in terminals, iTerm2 may be the Killer App for Macbooks.
You see, it has Tmux Integration [1], which makes tmux windows and panes become native tabs and panes in iTerm, which means I don't need to use weird chords to manipulate tmux, but most importantly, most UX-ily, it has native scrollback. No need to escape into a weird secondary mode just to do the most basic thing that all graphical terminals are good for.
If you work with terminals on remote machines, you owe yourself to use tmux. If your client is a Mac(book), you owe yourself to use iTerm2.
The weird thing is that iTerm2 is the only Terminal Emulator to leverage Tmux's Control Channel mode, for the integration. For all the breadth of copycat terminal emulators on Linux, none of them perform this one killer feature.
[1] https://iterm2.com/documentation-tmux-integration.html