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 think the first thing that stood out about tmux to me as a beginner was the unnatural use of prefix. I haven't used something like that before where you had to use prefix and then a particular command. It makes sense why it is the way it is, but feels odd in the beginning.
The bottom elements were part of it. Not the host name and time, but the window information. Also, it took a while to remember the default keys to use to get to session management window where tmux displays everything, among other things.
Vim's hjkl make sense as you start using the tool. tmux's Ctrl-B for a prefix doesn't make sense, so that leads to remapping.
I have checked out the UI's you have made - they look great - similar to what I would expect a custom tmux configuration to look like :)
> Vim's hjkl make sense as you start using the tool. tmux's Ctrl-B for a prefix doesn't make sense, so that leads to remapping.
Hmm, I'm still confused:
* How do Vim's hjkl start to make sense? They've always seemed arbitrary. 'l' should stand for 'left', but it takes me right!
* How is a different keyboard shortcut less confusing than ctrl-b. They all seem arbitrary. You remapped it to ctrl-a. Maybe you were used to GNU Screen?
The "what you think of them" part. I've been thinking hard about web site user interfaces, so not quite the same ballpark even. But, it struck me that we have all these 3D games where the navigation is ... well like adding another dimension. So why are we stuck in 2D so many places?
of a word cloud using @react-three/fiber for example. Imagine if I could have a little cloud floating for navigating tmux. A cloud not of words but sessions, windows, panes or whatever. If I could then I move around the 3d cloud from the keyboard .... Just an idea
I think 3D is a fine idea! Definitely worth trying in general.
In the context of this thread my mind was mostly on what it takes to make some arbitrary power UI "not dreadful", i.e. easy to understand for newcomers. Since it's a power tool, assume there'll be a learning curve. But the initial experience doesn't intimidate someone to start on that journey of a hundred miles of understanding how to use it with fluency and thereby augmenting themselves.
There have certainly been many intuitive 3D UIs. 3D games devote a lot of attention to being discoverable and friendly to newcomers, and they have a lot of success. However, my impression is that they achieve this success by dint of hard work. It's not clear that 3D makes the problem easier. If anything I'd be more likely to believe it makes it harder.
So if you have a product and are thinking about how to make it more intuitive (as I am), "make it 3D" is probably not the best suggestion. Does that seem reasonable? Let me know if I'm missing something.
I like your codepen. I wonder what it would feel like to use a whole note-taking app or digital garden with this metaphor. Rotate to a particular note until it's in front, then click on it to edit it. Perhaps you should stop moving in 3D while editing.
My guess, and only a guess, is that 3D is especially (only?) useful for navigation. As in moving around documents, panes, windows, etc.
As for "I wonder what it would feel like to use a whole note-taking app ..." The note taking is in some ways already done pretty well. So my current guess is that it is more the navigation that would benefit.
I don't really have answers, but I often feel like I live in 'flatland' these days.
don't know if you used lotus 123 back in the day, but it was one of the best keyboard-driven interfaces i've seen. everything was done by navigating hierarchical menus, but the menus were displayed horizontally in a bar on the bottom of the screen, no popups to obscure the rest of the display. so if you were a power user you would just automatically type e.g. /fs to open the file menu and then the save option thereunder, but if you were new to it you could look down, see that /f was file and when you hit that the bar would change to include s:save and you could hit that.
I remember those horizontal menus; Lotus 1-2-3 really was the pinnacle of productivity. You could also create custom menus, assign shortcut keys to your macros, and of course have your macros call other shortcut keys. I was too young to use it for serious work back then, but the 123 and dBase combo really was a powerhouse.
yeah, it went one step beyond wordstar because the menus did not drop down and cover up your screen, the menu was all horizontal, so if you knew the keystrokes via muscle memory you never saw menus flashing on the screen. i think nano does something similar these days.
Ohh, I see. It wasn't just a static menu bar at the bottom, but some hotkeys were modes and the menu bar would update when you pressed them. Pico/Pine still has something like that where ^o used to stand for "other commands" and the menu would show new hotkeys when you pressed it. I don't remember if Wordstar had some escape hatch like that. It certainly had a lot of commands.
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.
I think it depends on the use case. If I had to do what you do with random machines, I would probably need to be familiar with default tool setups as well
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!
You can't rebind plugin key maps and creating a new session conflicts with my preferred custom mode bindings. It's clear the devs are both rather opinionated and want to ship features, but they gotta clear stuff like that up, I'm not interested in doing that from CLI when tmux does this without issue.
0.41 included some "non-colliding keybind" option, and you can clear-defaults in the config now, so this issue might be fixed. I haven't tested it but I recall seeing news about it.
Last I tried it the bind issue and performance were sort of blockers for me, but it looks like both of those are moving forward.
I gotta admit that the initial experience in copy mode in tmux made me cringe a lot. The fact that scrolling up scrolled through the history of the terminal's commands was the most unexpected thing. After I enabled mouse use, it became usable for me.
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.
> Would love if built a similar, visually guided, experience for nvim.
Definitely would recommend checking out Helix. My brain is similar in that keybindings often don't stick - Helix has a grammar leading to a bit more of a visual interface (you select things first, and then edit, so you can see how things go as you carry out multi-cursor edits etc), but also, it'll show pop-up menus for shortcuts.
In normal mode for instance, "g" is "goto", pressing g also displays a little window that shows the different options and their keys. It's easy to ignore when you know what your doing, and super helpful when you can't remember something!
Should say that it's really similar to the tmux/zellij distinction, in that, helix works nicely out the box, but is a lot more opinionated, there's LSP support for pretty much all languages you'll use, but no plugin eco-system, so if you have a really customised, or AI based workflow for instance, your kinda stuck.
At least LazyVim[1] that I use does have visual help for key shortcuts - I can either press the first key (often prefix aka space) and get a popup of continuation keys, or use <space>sk to search keys.
@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 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 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.
> For daemonizing a single service, I agree it's silly. I think the argument becomes more complex when you have a whole group of service
I dont agree that a bunch of services makes things harder if it’s already easier as one service. The set up here is linear in effort. Plus, if anything, being able to restart the host and have all services automatically come up makes systemd much more convenient.
> 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.
logs are a literal one liner with systemd. Though if you care about dashboards then you should be exporting your logs to a proper observability platform instead of SSHing into your service.
> 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.
If you’re launching a service in a container then you don’t need either systemd nor tmux in that container because the container itself provides all that scaffolding for you.
Whether it’s Docker/podman, LXC, FreeBSD jails, Solaris Zones, etc, you just set your service to be the entry point of that container.
Docker makes this even easier still with a literal directive called “entrypoint”.
Trying to start services using tmux inside of a container is massively more effort than calling it directly from the entrypoint.
———
I do get the appeal of using tmux for these usages. I honestly do. And if your services are constant in flux, for example inference where you’re constantly tweaking parameters then tmux does make sense (a proper ML pipeline makes more sense, but that requires knowledgable MLOps to build). However for anything consistent, the effort in doing things “properly” is usually less than you think it is.
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.
For me, I use Spacebar as a leader key in Neovim, so I think they would conflict.
Does it ever create issues for you if you need to type the backtick in the terminal?
I found that Ctrl-A does a great job: it is conveniently located in relation to other keys that I need to interact with after I activate the prefix, and is in general easy to use.
I also use backtick for my tmux leader key. It doesn't create issues for me in the terminal (but you need to tap it twice when you want a literal backtick). This became natural for me pretty quickly.
I use F2 too. I can’t even remember why I started using it. I think maybe because KDE already had a similar binding so it because my de facto control pallet binding back before control pallets were a thing.
"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."
I'm puzzled how we get from unintuitive interface to "gatekeepy" (which I'm assuming implies a deliberate attempt to make the set of users small). Things can be difficult to use without anyone setting out to exclude new users, some things _are_ difficult to use, and other things are written by people who haven't been paid to make them address the needs of a wider range of users than they want to.
glaucon, I agree with you. Most of feeling of "gatekeepiness" came from being a novice at using tmux and having to get used to a new workflow. tmux is as gatekeepy as vim, or other complex cli tool is - if you have never used it in the past, you might find it to be a challenge. That was all I was trying to point out. It is an entry in a diary of a noob tmux user :D
I have checked it out initially. It hd a good set of defaults. I didn’t like everything that came with it, but I did read through its config file and borrowed a couple of lines from there into my own setup. IMO the problem with using a prebuilt config like that is that it requires you to learn all of its keybinds, styling, layout. I would rather build my own incrementally but have a sense of knowing everything that is going on in my setup.
Came here to post the same reference. The good thing about this repo is that you can configure everything in the .tmux.conf.local. I have this synced to all my machines using syncthing and symlinks to the user directory.
I also have my own keybindings, styling etc. - but this is an awesome base to get started.
I recently dove into Tmux just to be able to combine it with Claude-Code(CC): allowing CC to watch and interact with a CLI application in a separate pane. A nice feature of tmux is that it is scriptable, I.e allows programmatically sending keystrokes to a specific pane. So I built this little tool "tmux-cli" that creates a convenient, safe wrapper (that prevents self-killing, and has built-in delays for Enter key, etc) around tmux that lets CC spawn another pane, launch a CLI script and actually interact with it. This gives CC some interesting abilities: interact with CLI scripts expecting user input; spawn another instance of CC and give it a task (like sub-agents but fully-visible); launch a CLI script with a debugger like Pdb and stepping thru it; launch UI servers and use Puppeteer MCP to check the browser.
I use a window manager and have never bothered with tmux, except as a screen alternative to keep processes alive on servers every once in a while. I don’t like the idea of learning a 3rd set of key bindings in order to get what my window manager mostly gives me.
For those of you who use a tiling or scrolling window manager and tmux, what’s your selling point?
Yeah. I use it for that, but that's a pretty rare case for me. I'd like to hear from folks who use it as their dev environment in addition to a good window manager. In that scenario, it seems largely superfluous, though session resumption is nice.
I was sad to discover that not all string-like config items accept input from external processes. I had to resort to on-the-fly sed templating as a hackaround.
Have you used iTerm's built-in tmux integration? It's a while since I used it because I don't do development on a remote machine anymore, but I liked the way it mapped tmux tabs and panes to native iTerm ones
Speaking of prefix-key binding -- I find all control-key combos painful. I use the UHK split keyboard, and set mod-space as the prefix key which is very ergonomic.
I've largely given up using tmux in favor of wezterm: wezterm has the ability to remote connect to a persistent terminal running on another machine, and has native window objects so things like mouse support and copy/paste work out of the box. It also has a kind of mosh-like support, though not quite as good at persisting connections over bad networks or network disconnections as mosh+tmux.
The down side is that it's really sensitive to versions, right now I'm struggling to get it to work on NixOS in the version that I have running on my Ubuntu dev box and MacOS laptop.
As an emacs user, I struggle to see the purpose of tmux when emacs gives me a
lot of control of my screen layout.
I can see its purpose for vim users... maybe tmux can still have some features for neovim users. For emacs.. my answer is simply all-in emacs.
When I saw a screenshot of emacs in the article, I thought I was in for some education... but sadly not the case.
Maybe I am missing the point - but I am happy to learn.
>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
I have started using nvim about a year ago, and that one also took three separate tries before it finally stuck with me :) After that, about 8 months ago I found tmux and had a harsh "first impression".
These days I enjoy using both of those tools and get more excited the more I learn about them.
I tried LazyVim a couple of times, but felt that I would rather go back to a simpler nvim setup, and then build it up myself and learn as I go. I have stuck and enjoyed kickstart.nvim: https://github.com/nvim-lua/kickstart.nvim
It has been my starting point, and I have gradually been adding new plugins and reconfiguring existing ones.
The only reason to still use tmux (or screen) is because you use remote sessions. All modern terminal emulators are already capable of doing tabs and panes (okay, maybe not sessions, but some can locally). If you're using tmux for this reason, stop. Go pick up a modern terminal like ghostty, Alacritty, or WezTerm.
But why tmux still exists today is because people are working on computers they aren't sitting in front of. Because I don't want to have to be running nohup or detaching, moving to the background, and resetting the session so error messages don't appear in my active instance. Hell, technically I can do this with vim and get something pretty similar to tmux by using the terminal. But that's a pain.
I would mostly agree, but I like that I can use tmux locally and remotely and thus have the same interface wherever I do my work (and regardless of what terminal I use).
Then, there's the fact that some terminals capture too many keybindings and get in the way of some terminal code editors I'd like to use (e.g. recently I was again trying to use flow <https://github.com/neurocyte/flow> and its next-tab and previous-tab shortcuts clash with Ghostty's). If I had a terminal that 1) was nothing but a black box with the capability to display Unicode font glyphs and ligatures correctly, 2) works under Wayland, and 3) captures as few keybindings as possible, I'd use it locally with tmux and live happy.
> I like that I can use tmux locally and remotely and thus have the same interface wherever I do my work
The reason I don't do this (even though a trivial config could make this possible) is I want more indications that I'm remote vs local. I'll even change the remote status bar (sometimes theme) so there's more visual indication (an icon helps, but it quickly becomes invisible, just like the hostname). To be clear, I don't have a pattern for every machine, just 2: local vs remote. Everything remote starts with my tmux binding (<C-b> sucks and requires an absurd hand movement, so I use <C-s> because who freezes these days?). With this I still keep all my muscle memory but have a clear signal of "remote vs local" and prevents silly mistakes.
> (e.g. recently I was again trying to use flow <https://github.com/neurocyte/flow> and its next-tab and previous-tab shortcuts clash with Ghostty's)
I don't think I understand this example. There's only so many keybindings and clashes aren't uncommon. There's only 45 control commands (without shift or f-keys) and less than half are convenient due to reach (<C-6> sucks!). Even fewer when you start thinking about "sane defaults" and unfortunately those are biased by the past, so collisions become more likely.
Like I use vim so frequently hit <C-w> while typing and when I'm not on mac I kill browser tabs (probably for the best lol). But the benefit of all CLI programs is the config. There's no "one-size-fits-all" solution, so having configuration is the next best thing.
> If I had a terminal that
I'm not sure what emulator doesn't meet these goals. Foot is a barebones solution, so that might be good for you. But if the issue is clashing with keybindings then that's an unavoidable problem, though luckily solvable. At least the emulators tend to provide better flexibility in this respect than most programs do.
> I don't think I understand this example. There's only so many keybindings and clashes aren't uncommon.
That's precisely my point! Many terminals these days try to do too much and by default end up capturing keybindings that I want to use for something else. The terminal should allow me to do that something else, not get in the way. A simple terminal wouldn't get in my way and I could insert tmux in the more complex scenarios (even for local sessions). I know I can reconfigure most terminals, but not everything is configurable, plus everyone knows the best tools are the ones that don't require to be reconfigured to be great. :)
Thankfully my main editor is Helix and by default it doesn't clash with anything because it's a modal editor where commands are regular keystrokes and not key combinations.
> Foot is a barebones solution, so that might be good for you
I'm aware of foot, and it works fine, but it doesn't correctly display the fancy icons used by foot (and other programs). For a visual comparison, here's foot on the left, Ghostty on the right: <https://v1.imgpaste.net/images/public/21baee04-b4a5-4693-8a8...>
> I'm aware of foot, and it works fine, but it doesn't correctly display the fancy icons used by foot (and other programs).
These are icon glyphes. You have to set the font setting for the terminal to have them. By default, foot uses whatever you set for the monospace family (you can use the command `fc-match monospace` to find out which font). You may want to use a Nerd Font instead.
Yep, and that's all configuration I'd rather not have to spend time on. I was giving the Ghostty example to show how one of them Just Works™. (But the project goals might just be different, I'm not here to discredit Foot which is a really good terminal emulator.)
I think they are caught off-guard by the fact that (IIRC) ghostty and kitty (and wez?) come bundled with (or load) nerdfonts by default.
Also good command to know `fc-list`. It'll list the fonts on your system (you may want to pipe it into a pager: `fc-list | less`). There's a few fc- commands that deal with fonts for anyone facing these types of issues.
> The terminal should allow me to do that something else, not get in the way.
What terminal gets in the way? If there's a clash you do a remap.
I mean I really don't understand. Do you expect the terminal developer to know all the keybindings you currently use and will use in the future? That's a really big ask! Or are you asking that the terminal comes with no keybindings? I can understand that one, but I think it is not going to be popular. For most people that means more configuration. You can disable anything you don't like.
> Thankfully my main editor is Helix
FWIW I don't have clashes with vim despite vim having both of those
> I'm aware of foot
What font is foot using? It's been awhile, but I don't remember having this issue with foot. But IIRC on foot, and some other terminals, they don't know to use a nerd font by default or maybe just fail to find or prioritize.
Do you expect the terminal developer to know all the keybindings you currently use
i expect terminal developers to keep keybindings to a minimum.
come to think of it, i can't think if a single keybinding that i need from a gui terminal. the only keybindings i need from a terminal are those for tmux, so if a terminal replaces tmux (like wezterm is able to) then those are ok, but otherwise when i run tmux in a gnome terminal then there isn't a single key binding that i need for gnome, except possibly copy and paste.
sadly, i haven't been able to get this to work. whenever i turn mouse support on in tmux or in vim, copy-paste stops working completely. it works within tmux, but i can't copy anything from the terminal to other windows. i tried this with gnome terminal and wezterm. i could not find any setting in gnome terminal to change that. (wezterm i still need to check if there is a configurable option to turn this on).
also, very annoyingly, when i select something in tmux, the selection doesn't stay highlighted. i find that a serious issue that makes tmux selection annoying. another problem: clicking on urls to open them, which is a terminal feature, stops working too.
> i expect terminal developers to keep keybindings to a minimum.
This seems to be one of the goals of ghostty. I don't think keybinding for moving tabs/splits is excessive (as a default). I'd expect every emulator to come with defaults for those.
> there isn't a single key binding that i need for gnome, except possibly copy and paste.
You don't use new tab? New window? You physically click the tab to move tabs?
I mean I'm not trying to harp on your preferences, but I think you have unreasonable asks. I haven't used an emulator where you cannot change or remove those keybindings, so I think that solves your asks. But I think your asks are unreasonable because they don't match the requests of the majority of users. You're totally right that "sane defaults" are not going to be "sane" for everyone. But why isn't that fine? I mean that's why we have configs, right? So that we can make them our own? "Sane defaults" are just an attempt to minimize configuration by trying to match average demand, not try to match every person. I mean we all have dotfiles, right?
I'm just really lost in what you're asking for. You're asking that *defaults* match *your* needs, right?
Because it sounds like you're upset that keybindings exist so... disable them? Is there something you can't disable? I'm really lost here...
I don't think keybinding for moving tabs/splits is excessive
agreed.
You don't use new tab? New window? You physically click the tab to move tabs?
in gnome terminal i don't use tabs at all. i use tmux for that.
gnome has a number of keybindings, most of which start with shift-control, which is a rare combination not used elsewhere. in tmux all bindings start with a leader which is configurable, making it easy to stay away from other key combinations. wezterm can do that too. i am not the person you are originally responding to. i am happy if all keybindings can be changed with a single setting. i don't know if gnome terminal can do that, but it appears that gnome does exactly what we ask for: choose keybindings that don't get in the way.
Yes, of course. What I'm trying to communicate is that if you're just doing things locally you can get all the benefits (sin sessions) from modern terminal emulators. Most people are using panes and tabs but switching to another terminal emulator will get you these and much more. If you're using the default terminal emulator, you should probably switch (you're installing a program anyways, right?).
That said, I still use tmux. Almost every day in fact. Because all my work is being done on a machine I'm not sitting in front of. This even includes at home. My main desktop is connected to a TV for videogames and movies. When I want to do work on it there's no difference if I'm sitting in front of my laptop or it other than it sitting in my livingroom keeps it cooler and gives it better air flow.
Edit:
Locally: my terminal emulator (ghostty) can do everything tmux can. I can do sessions (windows), panes, tabs, and all that. But with ghostty I also get images, a lower memory footprint (than stock emulator), lower CPU usage (than stock emulator), ligatures, and everything else. It is strictly better.
But I can't do {widows,panes,tabs} with remote connections. Hence, tmux. Which in that case, I will frequently give up capabilities (like images) for that.
You don't mention the persistence of tmux sessions, which I find very useful for local development. Does ghostty have a client-server architecture too?
I mean having long processes(batch jobs, backups, compiling, etc...) or even your opened terminal apps like your code editor or claude code don't get interrupted/killed if you accidentally close your terminal, or you terminal/desktop environment crashes/freezes. While essential for doing dev on remote servers IMO cause of "networks", is useful for local stuff too.
Tmux is going to solve some problems that your standard emulator won't solve. I agree.
BUT
1) I'm unconvinced the things it solves that emulators don't do are common situations
2) tmux isn't "free". There are trade-offs that you have to make for tmux.
There's definitely edge cases where I do run tmux locally, but I find them rare and there's usually another solution (and I definitely do a lot more "weird things" than the average user will, so I run into more "edge cases").
But most users are turning to tmux for the {tabs,panes} feature (and then using sessions like anyone would use a window).
> interrupted/killed if you accidentally close your terminal
Sure, I get you, but I'm also not sure what tmux is doing for you in most cases. I'll give you that it's easier to kill your terminal pane than it is to kill the tmux server, but it is still easy to kill a pane or tab in tmux. I think there's better defenses here to prevent those mistakes. I mean you can just put a window in a different workspace and get very similar defenses as to what tmux is giving you. You're right, that isn't a reliable defense, but that's true about tmux here too.
If you have a process running that needs to stay alive for long periods of time then does it need to be running interactively? It is pretty rare that long running processes need be running interactively. Not rare in the sense that an average user is going to do this infrequently, but rare in the sense of few users are going to do this infrequently.
- You can always throw running jobs into the background by doing: <C-z> (suspend), `bg` (resumes program in background), and `detach` (so the process is not attached to the current terminal instance).
- If you're launching a job consider using `&`
- Remember, you can always reattach to a running process too. If you still have the terminal open it is trivial with `fg`. If you don't, then you can still attach with strace or gdb, but you'll probably need `sudo` and this isn't exactly trivial.
- If you know your job needs to be interacted with then there's better ways to handle that communication like by setting up a pipe. But that requires forethought.
- or the best option is to actually run it as a service since you'll get a lot more benefits and flexibility through that. It's pretty quick to turn anything into a systemd job.
- You can interact with systemd jobs if you set them up that way. Lots of fancy options here from ttys, pipe, sockets, or containerizations.
- systemd-nspawn or systemd-vmspawn. Containers are honestly the best option for long running but interactive jobs.
--- Aside ---
Batch jobs:
script and should run in the background. Are your batched jobs not scripted? Just copy paste your loop into a file and add the header. I typically add a few more lines for logging and stuff but yeah. I mean if I want that output I usually want that output longer than my session will be alive, so logs. That way they also are organized.
Backups:
unless you're doing a quick rsync then this really should be automated. A service is the solution. If you find yourself needing/wanting to manually run, you can also just call the systemd job. But yeah, if I have a one-time big sync, I'll pull up tmux (or caffeine). But that's different than always running in tmux.
Compiling:
I'll be honest, locally I rarely have long compiles (or anything over a few minutes). Anything that is long and repeated should be incrementally compiled. I mean this is a much more robust strategy anyways and in a long compile there's a lot of potential disruptions that are far more likely than me closing my terminal window. But in those rare instances I usually throw the process into the background (or start with `&`) or will turn on caffeine or whatever to keep my machine awake.
--- /Aside ---
> or you terminal/desktop environment crashes/freezes
This seems like a more complicated issue. Depends on the crash, right? But how often are you crashing? If frequently enough that you're going to default to running in tmux then I think you have bigger problems. Honestly, I don't think I can remember a time where only my DM or terminal crashed and the whole system didn't go down. Well... DM on a boot, but that's not the situation we're discussing. Maybe if I did something stupid like try to mess with the DM while the DM is running, but... I mean... tmux isn't going to fix the root problem... IDK if it will fix any problem there...
I'm not sure how often ghostty calls the window-save-state command but it looks like you should be able to call this frequently, though I haven't tried it and I'll give you this one because this definitely requires more work. Though ghostty will survive a reboot and you need a plugin for that with tmux. But either way, this is related to the lesson of backup often. Or commit frequently.
> While essential for doing dev on remote servers IMO cause of "networks"
If we're talking about remote, well that's why I use tmux every day. I didn't say there's no point to tmux, just that the vast majority of things it does *locally* can be accomplished without it.
I'm 100% supportive of tmux with remote connections.
If you're having that spotty connection then I think the better solution is using something like mosh or the best option is configuring better timeouts in ssh{,d}_config. Look at `TCPKeepAlive`, `ServerAliveInterval`, ServerAliveCountMax` (s/Server/Client/g for sshd_config)
I cannot phantom why anyone would write lengthy walls of text trying to convince people "no askhually, your workflow is invalid and theres a better way!11" after they've told you very directly and clearly several times that this works well for them. People have different preferences. People are telling you that this works well for them. They don't really don't need to be condescendingly "educated". Learn to listen.
Using tmux locally lets me use a single interface and interaction model for multiple sessions, regardless of whether they are local, remote, or a mix of both.
I'm not quite sure I understand your pattern. Can you explain it more so I can better understand? Maybe I'm missing something and I'm always looking to improve my workflow.
Locally, I don't get the point. I can do tabs and splits. A session? That's another window. I can also hide that and use keyboard shortcuts to navigate towards it. Am I missing a local benefit?
The session is the thing I use, and I do use tmux every day, but I exclusively use it when in ssh as on a local machine I have everything I need. You mention the hybrid, but isn't the point that the connection is ephemeral? We don't exactly want to keep it alive unless we are actively using the connection, right? This is what I'm not understanding about your mixed scenario. What is the difference between what you do and me just opening another pane in ghostty and doing the ssh there. I can't detach from ghostty, but I can save the window state (or move to a different window in a different workspace or just cycle through windows like I would a session) so when I quit it it resumes, but honestly, I rarely quit it. Keeping a remote connection alive while there's no active usage seems like a waste and it's just going to disconnect when I walk away from my machine anyways. So what is the difference?
I do find sessions tend to get unruley easily, and more easily than windows just do to being hidden another level deeper. It's not too bad when single user, but I'd still suggest organizing tabs over multiple sessions, in most cases. That's because it is easy to just leave something like an editor open and accidentally overwrite files. Someone just logs back in after awhile and types :x into vim (or :x!) without thinking. It's also just too easy to let sessions stale. I haven't worked with a single person (myself included) who did not have a tmux session that was inactive for at least a month more than their last login time. (Better than all the hanging VSCode sessions though) That's like people using srun to run slurm jobs instead of submitting a batch job into the queue. That's totally fine to do when you're sitting in front of the sim but if you walk away and the code errors or just ends before your session ends then you're just hogging a machine that could be used (there wasn't even a benefit to this either!). Locally, it's pretty much the same thing except locally I can do all my tabs and splits and sessions without tmux.
I have a status line indicator to show whether tmux is in Control mode.
So, even when nested, it's always clear what will happen. One nested session (two total) is manageable. Adding another gets annoying, but the need is rare.
I've also tried the status line indicator but it's difficult to balance between being too visible and invisible. So just leads to doing the right commands on the wrong session. Though I find any nested session is rarely needed. I mean locally, a session is a window so I do that.
I don't mean rendering of an icon so much as I mean that humans become blind to persistent things (and frequent things). Losing glasses on your head kinda thing. I don't find a mirror as helpful as having a fixed location to put my glasses when I'm done with them. Same strategy
But yeah, when I didn't have splits and things in my emulator I used something like you did. Make a remote section visually distinct. To a lot of extent I still do, just this isn't necessary through tmux anymore
Okay, but sessions are one of the best things about tmux.
Sessions aside, in my opinion tmux's flow is just better than terminal emulators I've tried. It slots into my brain in a way no terminal emulator's tabbing support ever has, and I have never found a terminal emulator who supported keybindings in such a sophisticated and seamless manner as tmux does.
I also concur with other commenters, who mention that having uniform multiplexing of shell windows between local and remote environments is super useful for muscle memory.
> Okay, but sessions are one of the best things about tmux.
Locally or remotely? Remotely I fully agree. But remotely I can't open a new window and my machine doesn't have different workspaces.
> Sessions aside
I'm curious about this actually. The opposite has been true in my experience. What keybindings are you missing? I can keybind essentially any script I want or any set of keystrokes.
> uniform multiplexing of shell windows between local and remote environments is super useful for muscle memory.
I actually have the opposite experience. I mean I can bind ghostty splits to be identical to my tmux bindings, that's not an issue and trivial to merge. But I keep them separate because it contextualizes if I'm "here" or "there". Similarly I ensure that remote sessions have a different PS1 line so there are visual indications of where I am other than one small icon. Without this I find that it is easy to forget which machine I'm in. Had too many problems where I was running commands on one machine thinking I was in another.
> having uniform multiplexing of shell windows between local and remote environments is super useful for muscle memory.
Yep, this is why I use the same .tmux.conf on my servers and my local machines. I don't have to care about my terminal emulator - I might be using a fully featured Windows Terminal or iTerm, or I might be using xterm or st on some spartan system. My navigation works the same everywhere.
Is this really a requirement of tmux though? I have essentially this. Essentially, because I purposefully change my prefix for my emulator to remind me if I'm local or remote (tmux), but other than that it is fairly uniform.
For me tmux ended up being the solution for my dev needs. With a little bit of time, I learnt the ropes and became more or less productive with the default setup. Afterwards, I made it my own.
Like you mention, tmux sessions was one of the biggest features that I enjoyed about this tool: it does the job and does it well. Aside from that I love that I can use Vim-bindings with it, that it feels very similar to Neovim for me, so using them together is a no-brainer. Learning a couple of specific keyboard shortcuts is all it takes to make me productive.
I haven't needed to use a remote session yet like you note. While working with tmux locally I have learnt about all of these other features that I will definitely be looking forward to using once the opportunity arises.
I don't doubt that tools like ghostty, Alacritty, or WezTerm are great. I have heard lots about the first two. And I do intend to check them out.
What would you say is your favorite terminal and why as it relates to local development experience use? Are there features that these tools have that tmux lacks?
So far, ghostty. I do also like Alacritty and WezTerm, and think kitty is overhyped (and Warp is a privacy nightmare). A thing I really like about ghostty is it is incredibly easy to maintain. By far my smallest config file. Basically my theme and a few custom bindings. To be honest, there isn't a huge difference between all of them, with some being better at one thing than another, but I think ghostty gets things good all around.
Btw, vim bindings should already be available in your emulator, without the need for tmux. You can set bash to use them (set -o vi) but I suggest migrating to zsh if you like using the cli. I'll also give you one fun command most people don't know. While holding control, press x then e (if you are already using zsh you might need to add `zle -N edit-command-line` to your rc file but <C-x><C-e> needs no config in bash). I guess I should also mention that in vim you can open a terminal (:help term)
> why as it relates to local development experience use?
All these emulators can do, locally, everything tmux can do and more. You just have to remember that a session is the same thing as a window. All these emulators have tabs and splits. So there is no real advantage to tmux.
> Are there features that these tools have that tmux lacks?
First off, switch because your emulator is probably more resource intensive. It may also be missing modern features like being able to view images (see sixel, chafa, or the kitty graphics protocol), ligatures, and a lot of other features.
Second, tmux lacks many of these modern features. Doing a passthrough can help but dealing with images is not a great experience. I have found no configuration where I can reliably view images and never have been able to produce images of the same quality. I always drop out of my session if I am entering a file browser like yazi or fzf (I'll use fzf but it limits the capabilities of previewing).
I feel compelled to reply, because a lot of this contradicts my experience. I use wezterm + tmux on linux, iterm + tmux on mac. (Already an advantage there, tbh)
> vim bindings should already be available in your emulator, without the need for tmux
They may mean things like the vim-tmux navigator plugin, which makes it so if you hit e.g. the left-most window in vim and hit your go-left keybinding, it will go one tmux pane to the left. It's pretty crazy how seamless it is, and it's made possible by the fact that you can query tmux outside of the process and run commands on your running sessions, which I'm not sure you can do with any of the standalone terminals?
Tmux also doesn't prevent you from using c-x e. I'm aware of the vim terminal, but I'm very picky about my multiplexing and have not been satisfied by any built-in terminal in any editor.
> You just have to remember that a session is the same thing as a window.
A session is certainly NOT a window. It is a buffer. There is a difference, and that difference matters and comes with advantages that are separate from the advantages of windows.
> First off, switch because your emulator is probably more resource intensive
I'm not entirely sure if this is true, but it's utterly uncompelling to me. Holding my binding for 'switch window' will switch through n windows faster than I can mentally digest, and the lag is lighter than any gui app I've used.
> It may also be missing modern features like being able to view images (see sixel, chafa, or the kitty graphics protocol), ligatures, and a lot of other features
I'm not sure why you'd assume this? My setup (wezterm or iterm + tmux + fira code) indeed has ligatures and sharp image viewing passed through the multiplexer
> Second, tmux lacks many of these modern features. Doing a passthrough can help but dealing with images is not a great experience. I have found no configuration where I can reliably view images and never have been able to produce images of the same quality. I always drop out of my session if I am entering a file browser like yazi or fzf
Yazi is exactly what I use, and it works great with iTerm + tmux or wezterm + tmux.
I really don't want my terminal to do that much for me to be honest. I change terminals every couple years, and it's nice to not have to fuss around with them whenever that happens. I haven't changed my tmux config in about 15 years
Appreciate the detailed answer! I will need to take a look at different terminals to see if there is any other one that can better fit my needs.
I prefer the idea of having one tool to manage everything: from local flow to remote sessions. And I usually do not view images in the terminal. But I'm willing to put them to the test and see if I like one of those more.
> I prefer the idea of having one tool to manage everything: from local flow to remote sessions.
This is still achieved. But as outlined here and elsewhere, a single extra keypress is not so much a hindrance as it is a reminder of be being local vs remote.
I'll add that your muscle memory will adapt to whatever pretty quickly. Like I was switching between a mac and a linux machine with a keyboard frequently and it only took a week to forget where my pinky needed to go to hit ctrl. Same is true even if your bindings for whatever are not identical local or remote (though mine are very similar, just differing in the prefix). So I'd say when testing things make sure you include a burn-in time, otherwise any change is going to make all other options feel worse.
> I usually do not view images in the terminal.
I work in computer vision (ML) so this is a very useful feature. But given that essentially everything else is the same, things don't really feel that different when remote vs local. Just a little purposeful visual indication and a different prefix (which is on purpose).
I use ghostty and native splits, however there is no way to move a pane to a new tab. Which you can do in tmux very easily. That's one thing I wish it could do.
While this doesn't address that issue you can move a tab to a new window (session) as well as merge. I do wish this feature existed, but I use it so rarely that honestly I don't notice. Rarely are more than one pane essential in a given tab, so usually I solve this by cleanup. But yeah, I will acknowledge that limit.
When I was a Vim user, tmux was always the first thing I ran when connecting to a machine…
But the after moving to Emacs and using Tramp for remote sessions, followed by VS Code with its built-in session management, I never feel the need to even leave the editor let along manage sessions
How do you deal with persistent sessions in VSCode? I have a remote VM to which I connect through SSH using VSCode, but I need to have certain programs running even after I disconnect from the VM. It's the only reason why I use tmux and I haven't been able to get rid of it.
I use an ssh virtual host pattern *-tmux to copy over an ssh-specific tmux.conf to a remote host before connect and then connect to it with -f tmux-ssh.conf. I can also connect to a host directly without tmux stuff by omitting the -tmux suffix.
Which would require creating a couple of hundred (in my case) duplicate host aliases instead of adding one shell alias that can be used with any host, including those not mentioned in ~/.ssh/config.
For me the value in using a tool like tmux is that it remains scriptable - startup scripts - and could be used in conjunction with other cli tools. The same applies to Vim/Neovim. Both of these tools remain unrivaled in regards to combining them with other flows and pipelines.
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.
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...
The bottom elements were part of it. Not the host name and time, but the window information. Also, it took a while to remember the default keys to use to get to session management window where tmux displays everything, among other things.
Vim's hjkl make sense as you start using the tool. tmux's Ctrl-B for a prefix doesn't make sense, so that leads to remapping.
I have checked out the UI's you have made - they look great - similar to what I would expect a custom tmux configuration to look like :)
Hmm, I'm still confused:
* How do Vim's hjkl start to make sense? They've always seemed arbitrary. 'l' should stand for 'left', but it takes me right!
* How is a different keyboard shortcut less confusing than ctrl-b. They all seem arbitrary. You remapped it to ctrl-a. Maybe you were used to GNU Screen?
Ctrl-B is a mechanically more difficult key binding than Ctrl-A.
Here is a codepen example
https://codesandbox.io/p/sandbox/yup2o
of a word cloud using @react-three/fiber for example. Imagine if I could have a little cloud floating for navigating tmux. A cloud not of words but sessions, windows, panes or whatever. If I could then I move around the 3d cloud from the keyboard .... Just an idea
In the context of this thread my mind was mostly on what it takes to make some arbitrary power UI "not dreadful", i.e. easy to understand for newcomers. Since it's a power tool, assume there'll be a learning curve. But the initial experience doesn't intimidate someone to start on that journey of a hundred miles of understanding how to use it with fluency and thereby augmenting themselves.
There have certainly been many intuitive 3D UIs. 3D games devote a lot of attention to being discoverable and friendly to newcomers, and they have a lot of success. However, my impression is that they achieve this success by dint of hard work. It's not clear that 3D makes the problem easier. If anything I'd be more likely to believe it makes it harder.
So if you have a product and are thinking about how to make it more intuitive (as I am), "make it 3D" is probably not the best suggestion. Does that seem reasonable? Let me know if I'm missing something.
I like your codepen. I wonder what it would feel like to use a whole note-taking app or digital garden with this metaphor. Rotate to a particular note until it's in front, then click on it to edit it. Perhaps you should stop moving in 3D while editing.
My guess, and only a guess, is that 3D is especially (only?) useful for navigation. As in moving around documents, panes, windows, etc.
As for "I wonder what it would feel like to use a whole note-taking app ..." The note taking is in some ways already done pretty well. So my current guess is that it is more the navigation that would benefit.
I don't really have answers, but I often feel like I live in 'flatland' these days.
If anyone is curious, there is a Linux port of Lotus123:
https://github.com/taviso/123elf
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.
I do like the repo idea, but I wonder if there’s an easier and maybe faster way to do it over the SSH tunnel
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!
Last I tried it the bind issue and performance were sort of blockers for me, but it looks like both of those are moving forward.
https://github.com/zellij-org/zellij/releases/tag/v0.41.0
I have definitely felt that. Customization wasn't necessarily straightforward - just required some time spent reading the docs.
I appreciate the heads up about the "no install, try in shell" option. I will make sure to take a look!
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.
Definitely would recommend checking out Helix. My brain is similar in that keybindings often don't stick - Helix has a grammar leading to a bit more of a visual interface (you select things first, and then edit, so you can see how things go as you carry out multi-cursor edits etc), but also, it'll show pop-up menus for shortcuts.
In normal mode for instance, "g" is "goto", pressing g also displays a little window that shows the different options and their keys. It's easy to ignore when you know what your doing, and super helpful when you can't remember something!
Should say that it's really similar to the tmux/zellij distinction, in that, helix works nicely out the box, but is a lot more opinionated, there's LSP support for pretty much all languages you'll use, but no plugin eco-system, so if you have a really customised, or AI based workflow for instance, your kinda stuck.
[1] https://lazyvim.org
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
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:
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.
I dont agree that a bunch of services makes things harder if it’s already easier as one service. The set up here is linear in effort. Plus, if anything, being able to restart the host and have all services automatically come up makes systemd much more convenient.
> 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.
logs are a literal one liner with systemd. Though if you care about dashboards then you should be exporting your logs to a proper observability platform instead of SSHing into your service.
> such as being able to ctrl-c a pane and trivially re-launch it.
Is less effort than > 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.If you’re launching a service in a container then you don’t need either systemd nor tmux in that container because the container itself provides all that scaffolding for you.
Whether it’s Docker/podman, LXC, FreeBSD jails, Solaris Zones, etc, you just set your service to be the entry point of that container.
Docker makes this even easier still with a literal directive called “entrypoint”.
Trying to start services using tmux inside of a container is massively more effort than calling it directly from the entrypoint.
———
I do get the appeal of using tmux for these usages. I honestly do. And if your services are constant in flux, for example inference where you’re constantly tweaking parameters then tmux does make sense (a proper ML pipeline makes more sense, but that requires knowledgable MLOps to build). However for anything consistent, the effort in doing things “properly” is usually less than you think it is.
[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
Other than that, I always use the default CTRL+B (MOD) and rarely if ever do anything other than the following:
- MOD + d to detach, "tmux a" to attach
- MOD + c to create new window
- MOD + % to create new split pane, " for horizontal
- MOD + space to change between pane layouts
- MOD + pgup to scroll in buffer
Does it ever create issues for you if you need to type the backtick in the terminal?
I found that Ctrl-A does a great job: it is conveniently located in relation to other keys that I need to interact with after I activate the prefix, and is in general easy to use.
I've been using Ctrl+Q, it replaces an almost completely useless key combo (flow control if I'm not mistaken), and is easy to press.
I'm puzzled how we get from unintuitive interface to "gatekeepy" (which I'm assuming implies a deliberate attempt to make the set of users small). Things can be difficult to use without anyone setting out to exclude new users, some things _are_ difficult to use, and other things are written by people who haven't been paid to make them address the needs of a wider range of users than they want to.
I also have my own keybindings, styling etc. - but this is an awesome base to get started.
It's easy to install via uv:
https://github.com/pchalasani/claude-code-toolsFor those of you who use a tiling or scrolling window manager and tmux, what’s your selling point?
Glad that that it supports XDG though.
The down side is that it's really sensitive to versions, right now I'm struggling to get it to work on NixOS in the version that I have running on my Ubuntu dev box and MacOS laptop.
But only customization so far is metahar = C-b, because C-a needed on Emacs.
I can see its purpose for vim users... maybe tmux can still have some features for neovim users. For emacs.. my answer is simply all-in emacs. When I saw a screenshot of emacs in the article, I thought I was in for some education... but sadly not the case.
Maybe I am missing the point - but I am happy to learn.
Typical Macintosh user.
I have started using nvim about a year ago, and that one also took three separate tries before it finally stuck with me :) After that, about 8 months ago I found tmux and had a harsh "first impression".
These days I enjoy using both of those tools and get more excited the more I learn about them.
It's modular and customizable.
It has been my starting point, and I have gradually been adding new plugins and reconfiguring existing ones.
The only reason to still use tmux (or screen) is because you use remote sessions. All modern terminal emulators are already capable of doing tabs and panes (okay, maybe not sessions, but some can locally). If you're using tmux for this reason, stop. Go pick up a modern terminal like ghostty, Alacritty, or WezTerm.
But why tmux still exists today is because people are working on computers they aren't sitting in front of. Because I don't want to have to be running nohup or detaching, moving to the background, and resetting the session so error messages don't appear in my active instance. Hell, technically I can do this with vim and get something pretty similar to tmux by using the terminal. But that's a pain.
Tmux is for *terminals*
Then, there's the fact that some terminals capture too many keybindings and get in the way of some terminal code editors I'd like to use (e.g. recently I was again trying to use flow <https://github.com/neurocyte/flow> and its next-tab and previous-tab shortcuts clash with Ghostty's). If I had a terminal that 1) was nothing but a black box with the capability to display Unicode font glyphs and ligatures correctly, 2) works under Wayland, and 3) captures as few keybindings as possible, I'd use it locally with tmux and live happy.
Like I use vim so frequently hit <C-w> while typing and when I'm not on mac I kill browser tabs (probably for the best lol). But the benefit of all CLI programs is the config. There's no "one-size-fits-all" solution, so having configuration is the next best thing.
I'm not sure what emulator doesn't meet these goals. Foot is a barebones solution, so that might be good for you. But if the issue is clashing with keybindings then that's an unavoidable problem, though luckily solvable. At least the emulators tend to provide better flexibility in this respect than most programs do.That's precisely my point! Many terminals these days try to do too much and by default end up capturing keybindings that I want to use for something else. The terminal should allow me to do that something else, not get in the way. A simple terminal wouldn't get in my way and I could insert tmux in the more complex scenarios (even for local sessions). I know I can reconfigure most terminals, but not everything is configurable, plus everyone knows the best tools are the ones that don't require to be reconfigured to be great. :)
Thankfully my main editor is Helix and by default it doesn't clash with anything because it's a modal editor where commands are regular keystrokes and not key combinations.
> Foot is a barebones solution, so that might be good for you
I'm aware of foot, and it works fine, but it doesn't correctly display the fancy icons used by foot (and other programs). For a visual comparison, here's foot on the left, Ghostty on the right: <https://v1.imgpaste.net/images/public/21baee04-b4a5-4693-8a8...>
These are icon glyphes. You have to set the font setting for the terminal to have them. By default, foot uses whatever you set for the monospace family (you can use the command `fc-match monospace` to find out which font). You may want to use a Nerd Font instead.
[0]: https://www.nerdfonts.com/
Also good command to know `fc-list`. It'll list the fonts on your system (you may want to pipe it into a pager: `fc-list | less`). There's a few fc- commands that deal with fonts for anyone facing these types of issues.
I mean I really don't understand. Do you expect the terminal developer to know all the keybindings you currently use and will use in the future? That's a really big ask! Or are you asking that the terminal comes with no keybindings? I can understand that one, but I think it is not going to be popular. For most people that means more configuration. You can disable anything you don't like.
FWIW I don't have clashes with vim despite vim having both of those What font is foot using? It's been awhile, but I don't remember having this issue with foot. But IIRC on foot, and some other terminals, they don't know to use a nerd font by default or maybe just fail to find or prioritize.i expect terminal developers to keep keybindings to a minimum.
come to think of it, i can't think if a single keybinding that i need from a gui terminal. the only keybindings i need from a terminal are those for tmux, so if a terminal replaces tmux (like wezterm is able to) then those are ok, but otherwise when i run tmux in a gnome terminal then there isn't a single key binding that i need for gnome, except possibly copy and paste.
also, very annoyingly, when i select something in tmux, the selection doesn't stay highlighted. i find that a serious issue that makes tmux selection annoying. another problem: clicking on urls to open them, which is a terminal feature, stops working too.
I mean I'm not trying to harp on your preferences, but I think you have unreasonable asks. I haven't used an emulator where you cannot change or remove those keybindings, so I think that solves your asks. But I think your asks are unreasonable because they don't match the requests of the majority of users. You're totally right that "sane defaults" are not going to be "sane" for everyone. But why isn't that fine? I mean that's why we have configs, right? So that we can make them our own? "Sane defaults" are just an attempt to minimize configuration by trying to match average demand, not try to match every person. I mean we all have dotfiles, right?
I'm just really lost in what you're asking for. You're asking that *defaults* match *your* needs, right?
Because it sounds like you're upset that keybindings exist so... disable them? Is there something you can't disable? I'm really lost here...
agreed.
You don't use new tab? New window? You physically click the tab to move tabs?
in gnome terminal i don't use tabs at all. i use tmux for that.
gnome has a number of keybindings, most of which start with shift-control, which is a rare combination not used elsewhere. in tmux all bindings start with a leader which is configurable, making it easy to stay away from other key combinations. wezterm can do that too. i am not the person you are originally responding to. i am happy if all keybindings can be changed with a single setting. i don't know if gnome terminal can do that, but it appears that gnome does exactly what we ask for: choose keybindings that don't get in the way.
This may be of use to you or someone else reading the thread. You can set your bash prompt to show user@host when connected via SSH:
Do you think it's possible that someone might have a different workflow from you and tmux fits their use case in a way you haven't thought of?
That said, I still use tmux. Almost every day in fact. Because all my work is being done on a machine I'm not sitting in front of. This even includes at home. My main desktop is connected to a TV for videogames and movies. When I want to do work on it there's no difference if I'm sitting in front of my laptop or it other than it sitting in my livingroom keeps it cooler and gives it better air flow.
Edit:
Locally: my terminal emulator (ghostty) can do everything tmux can. I can do sessions (windows), panes, tabs, and all that. But with ghostty I also get images, a lower memory footprint (than stock emulator), lower CPU usage (than stock emulator), ligatures, and everything else. It is strictly better.
But I can't do {widows,panes,tabs} with remote connections. Hence, tmux. Which in that case, I will frequently give up capabilities (like images) for that.
You don't need a server to handle this feature. Using a non-server solution even allows restoring after power cycles!
[0] https://ghostty.org/docs/config/reference#window-save-state
But most users are turning to tmux for the {tabs,panes} feature (and then using sessions like anyone would use a window).
Sure, I get you, but I'm also not sure what tmux is doing for you in most cases. I'll give you that it's easier to kill your terminal pane than it is to kill the tmux server, but it is still easy to kill a pane or tab in tmux. I think there's better defenses here to prevent those mistakes. I mean you can just put a window in a different workspace and get very similar defenses as to what tmux is giving you. You're right, that isn't a reliable defense, but that's true about tmux here too.If you have a process running that needs to stay alive for long periods of time then does it need to be running interactively? It is pretty rare that long running processes need be running interactively. Not rare in the sense that an average user is going to do this infrequently, but rare in the sense of few users are going to do this infrequently.
This seems like a more complicated issue. Depends on the crash, right? But how often are you crashing? If frequently enough that you're going to default to running in tmux then I think you have bigger problems. Honestly, I don't think I can remember a time where only my DM or terminal crashed and the whole system didn't go down. Well... DM on a boot, but that's not the situation we're discussing. Maybe if I did something stupid like try to mess with the DM while the DM is running, but... I mean... tmux isn't going to fix the root problem... IDK if it will fix any problem there...I'm not sure how often ghostty calls the window-save-state command but it looks like you should be able to call this frequently, though I haven't tried it and I'll give you this one because this definitely requires more work. Though ghostty will survive a reboot and you need a plugin for that with tmux. But either way, this is related to the lesson of backup often. Or commit frequently.
If we're talking about remote, well that's why I use tmux every day. I didn't say there's no point to tmux, just that the vast majority of things it does *locally* can be accomplished without it.I'm 100% supportive of tmux with remote connections.
If you're having that spotty connection then I think the better solution is using something like mosh or the best option is configuring better timeouts in ssh{,d}_config. Look at `TCPKeepAlive`, `ServerAliveInterval`, ServerAliveCountMax` (s/Server/Client/g for sshd_config)
Locally, I don't get the point. I can do tabs and splits. A session? That's another window. I can also hide that and use keyboard shortcuts to navigate towards it. Am I missing a local benefit?
The session is the thing I use, and I do use tmux every day, but I exclusively use it when in ssh as on a local machine I have everything I need. You mention the hybrid, but isn't the point that the connection is ephemeral? We don't exactly want to keep it alive unless we are actively using the connection, right? This is what I'm not understanding about your mixed scenario. What is the difference between what you do and me just opening another pane in ghostty and doing the ssh there. I can't detach from ghostty, but I can save the window state (or move to a different window in a different workspace or just cycle through windows like I would a session) so when I quit it it resumes, but honestly, I rarely quit it. Keeping a remote connection alive while there's no active usage seems like a waste and it's just going to disconnect when I walk away from my machine anyways. So what is the difference?
I do find sessions tend to get unruley easily, and more easily than windows just do to being hidden another level deeper. It's not too bad when single user, but I'd still suggest organizing tabs over multiple sessions, in most cases. That's because it is easy to just leave something like an editor open and accidentally overwrite files. Someone just logs back in after awhile and types :x into vim (or :x!) without thinking. It's also just too easy to let sessions stale. I haven't worked with a single person (myself included) who did not have a tmux session that was inactive for at least a month more than their last login time. (Better than all the hanging VSCode sessions though) That's like people using srun to run slurm jobs instead of submitting a batch job into the queue. That's totally fine to do when you're sitting in front of the sim but if you walk away and the code errors or just ends before your session ends then you're just hogging a machine that could be used (there wasn't even a benefit to this either!). Locally, it's pretty much the same thing except locally I can do all my tabs and splits and sessions without tmux.
So, even when nested, it's always clear what will happen. One nested session (two total) is manageable. Adding another gets annoying, but the need is rare.
Here's what I use:
Right side included just for completeness. The conditional colour setting was the useful part, IIRC.But yeah, when I didn't have splits and things in my emulator I used something like you did. Make a remote section visually distinct. To a lot of extent I still do, just this isn't necessary through tmux anymore
Okay, but sessions are one of the best things about tmux.
Sessions aside, in my opinion tmux's flow is just better than terminal emulators I've tried. It slots into my brain in a way no terminal emulator's tabbing support ever has, and I have never found a terminal emulator who supported keybindings in such a sophisticated and seamless manner as tmux does.
I also concur with other commenters, who mention that having uniform multiplexing of shell windows between local and remote environments is super useful for muscle memory.
Yep, this is why I use the same .tmux.conf on my servers and my local machines. I don't have to care about my terminal emulator - I might be using a fully featured Windows Terminal or iTerm, or I might be using xterm or st on some spartan system. My navigation works the same everywhere.
Like you mention, tmux sessions was one of the biggest features that I enjoyed about this tool: it does the job and does it well. Aside from that I love that I can use Vim-bindings with it, that it feels very similar to Neovim for me, so using them together is a no-brainer. Learning a couple of specific keyboard shortcuts is all it takes to make me productive.
I haven't needed to use a remote session yet like you note. While working with tmux locally I have learnt about all of these other features that I will definitely be looking forward to using once the opportunity arises.
I don't doubt that tools like ghostty, Alacritty, or WezTerm are great. I have heard lots about the first two. And I do intend to check them out.
What would you say is your favorite terminal and why as it relates to local development experience use? Are there features that these tools have that tmux lacks?
Btw, vim bindings should already be available in your emulator, without the need for tmux. You can set bash to use them (set -o vi) but I suggest migrating to zsh if you like using the cli. I'll also give you one fun command most people don't know. While holding control, press x then e (if you are already using zsh you might need to add `zle -N edit-command-line` to your rc file but <C-x><C-e> needs no config in bash). I guess I should also mention that in vim you can open a terminal (:help term)
All these emulators can do, locally, everything tmux can do and more. You just have to remember that a session is the same thing as a window. All these emulators have tabs and splits. So there is no real advantage to tmux. First off, switch because your emulator is probably more resource intensive. It may also be missing modern features like being able to view images (see sixel, chafa, or the kitty graphics protocol), ligatures, and a lot of other features.Second, tmux lacks many of these modern features. Doing a passthrough can help but dealing with images is not a great experience. I have found no configuration where I can reliably view images and never have been able to produce images of the same quality. I always drop out of my session if I am entering a file browser like yazi or fzf (I'll use fzf but it limits the capabilities of previewing).
> vim bindings should already be available in your emulator, without the need for tmux
They may mean things like the vim-tmux navigator plugin, which makes it so if you hit e.g. the left-most window in vim and hit your go-left keybinding, it will go one tmux pane to the left. It's pretty crazy how seamless it is, and it's made possible by the fact that you can query tmux outside of the process and run commands on your running sessions, which I'm not sure you can do with any of the standalone terminals?
Tmux also doesn't prevent you from using c-x e. I'm aware of the vim terminal, but I'm very picky about my multiplexing and have not been satisfied by any built-in terminal in any editor.
> You just have to remember that a session is the same thing as a window.
A session is certainly NOT a window. It is a buffer. There is a difference, and that difference matters and comes with advantages that are separate from the advantages of windows.
> First off, switch because your emulator is probably more resource intensive
I'm not entirely sure if this is true, but it's utterly uncompelling to me. Holding my binding for 'switch window' will switch through n windows faster than I can mentally digest, and the lag is lighter than any gui app I've used.
> It may also be missing modern features like being able to view images (see sixel, chafa, or the kitty graphics protocol), ligatures, and a lot of other features
I'm not sure why you'd assume this? My setup (wezterm or iterm + tmux + fira code) indeed has ligatures and sharp image viewing passed through the multiplexer
> Second, tmux lacks many of these modern features. Doing a passthrough can help but dealing with images is not a great experience. I have found no configuration where I can reliably view images and never have been able to produce images of the same quality. I always drop out of my session if I am entering a file browser like yazi or fzf
Yazi is exactly what I use, and it works great with iTerm + tmux or wezterm + tmux.
I really don't want my terminal to do that much for me to be honest. I change terminals every couple years, and it's nice to not have to fuss around with them whenever that happens. I haven't changed my tmux config in about 15 years
I prefer the idea of having one tool to manage everything: from local flow to remote sessions. And I usually do not view images in the terminal. But I'm willing to put them to the test and see if I like one of those more.
I'll add that your muscle memory will adapt to whatever pretty quickly. Like I was switching between a mac and a linux machine with a keyboard frequently and it only took a week to forget where my pinky needed to go to hit ctrl. Same is true even if your bindings for whatever are not identical local or remote (though mine are very similar, just differing in the prefix). So I'd say when testing things make sure you include a burn-in time, otherwise any change is going to make all other options feel worse.
I work in computer vision (ML) so this is a very useful feature. But given that essentially everything else is the same, things don't really feel that different when remote vs local. Just a little purposeful visual indication and a different prefix (which is on purpose).But the after moving to Emacs and using Tramp for remote sessions, followed by VS Code with its built-in session management, I never feel the need to even leave the editor let along manage sessions
Though I agree, probably not the best solution to start all sessions with tmux. There's other issues it can cause.