Unfortunately, my conclusion was that the only independent character-based terminal tradition is IBM’s 3270 stuff, but even setting aside IBM weirdness it’s simply not that. (Yes, there’s also such a protocol within tmux but it’s not really compatible with anything else.)
Start thinking of tmux, screen, ssh, etc as terminal emulators, and everything will suddenly make sense.
> perhaps we should rethink protocols etc to make many of these features more native
I've been opposing terminal emulators (NOTE: emulators, not REPLs) for a long while. I also do believe we can collectively do better than emulating 1970s hardware. I do believe we can build applications where "ctrl-c" means copy, and selecting more than one screen's worth of text is possible. It's not hard, we're just stubborn.
but i agree with your general point: we can collectively do better than emulating 1970s hardware
absolutely!
VT102 wasn't designed with multiplexing in mind. The device was meant as a primary way to interact with a computer, not to perform the tasks of one - your physical keyboard also doesn't understand "copy".
> selecting more than one screens worth of text is possible in gui terminals and also in tmux.
It is but it isn't. You want to copy a multiline snippet of code you just wrote, you will have to manually strip away $PS1 & $PS2. You want to copy from vi into another window, you can't use the mouse - and you have to use a side channel.
I have 20+ unfixable issues outlined, and I'm in the process of writing a blog post... But at my current rate, it could become a book.
ok, yes, i was just talking about the simple case. you are right that the issue is more complicated, so i actually agree with you. i am talking about similar problems here: https://news.ycombinator.com/item?id=44757142
i am looking forward to your post. i added your blog to my rss reader
Apple provided a new modifier key (Command, or ⌘) for our GUI shell. Or Open Apple/Closed Apple if you go back to the Apple II days. Control still works like it should.
Microsoft said "Hey that's useful, but we don't make hardware, and we don't have a Command key, so let's break things and reuse Control in our copycat GUI, and ignore all of the historical uses of control characters. What could go wrong?"
And then Linux (Gnome??) said "Hey we don't make hardware either, let's do what Microsoft did, because lots of people are familiar with it, and even though the historical uses of control characters are really important on Unix-like operating systems."
But I agree that tmux sessions are convenient.
It is also extensible.
This isn't about reinventing tmux poorly. They're trying to keep their workflow without having a muxer in the middle that needs to understand and translate every feature of the protocol, which is the core concept and the major problem with tmux.
If you do splits client side, you don't have any software middlebox trying to interpret the traffic, so you keep native scrollback and all the fancy features of your terminal are still here.
That's what the blog post is about. Not reinventing tmux, but getting rid of the muxing.
AFAIK this doesn't exist, so I'm using tmux...
So terminal clients just have to implement this protocol... it's already implemented in iTerm2
- https://github.com/MLFlexer/smart_workspace_switcher.wezterm
I generally have a single session I care about per machine (rather than per project) and wezterm's built-in multiplexing handles this out of the box.
Also, if you do physically connect to a headless machine, it's nice to not need to keep having to open a new getty session (or be able to log out of a session) ;)
the key benefit is i only need to learn one set of commands to switch sessions and windows, and to create new windows.
the sessions all run in a single terminal window, so when i have multiple other windows, i don't have to switch between them to find the right terminal window. terminals have tabs, but they don't group tabs into sessions. a single terminal with 19 tabs would not work.
i use the gui to start the terminal. i would have to find out how to script starting a terminal with multiple tabs. tmux is more easily scriptable, and again, i can't avoid learning tmux, since i use it remotely, and so when using it locally too, i don't have to learn a different way for my local machine.
finally, although rarely needed, i can log out, or my gui can crash, but the tmux sessions survive. i can also connect to my laptop from a different device and attach to the tmux sessions that way.
for a gui terminal to replace tmux the foremost feature i need is for it to remember my windows and tabs, just like the browser does. i have not come across any terminal that does that (but i admit, i haven't done a exhaustive search either). gnome (or any WM) can remember which apps i have open, but it can't remember the state inside the apps.
being able to reproduce state is really the key. i have a few vim sessions for example, easily remembered and recalled from my command line history. i could use gvim if i could figure out how to connect a gvim window with a terminal such that they form one unit, because every vim session is connected a number of commandline operations. (i believe BeOS/haiku can potentially do that based on the way its window tabs work)
Any particular reason why you cannot simply use su or sudo for this?
I don't use a tiling WM, and tmux[1] does an excellent job at the tiling features.
I do the majority of my work physically at a Linux (Fedora) desktop, but I also work from home SSH'd to that desktop. Being able to just attach to the same session and pick up where I left off, with all the same shell management, is great.
[1] I used tmux for years, but have very recently switched to Zellij. I find the pane navigation to be much smoother (and more discoverable).
WezTerm is not necessarily something I want to deploy and keep up to date on hundreds of machines, screen/tmux are still fine for that.
https://www.masteringemacs.org/article/replacing-tmux-gnu-sc...
Yes, if you only have one or two terminal sessions or open web pages then you can probably live without using them, but anything beyond that leads you into reimplementing features to cope with your desktop's lack of ability to manage dozens of windows.
I have all my terminals with distinct icons and background colours to tell them apart. The operating system (Windows) does the heavy lifting.
i tried Mac for about five years but missed MS Windows “every window can be alt tabbed to”. Mac has “every app can be command tabbed to and therein each app has its own subwindow management”
This is so, so annoying. Your Mac app’s window is minimized? No alt-tab for you!
I regularly minimize some applications when I want to focus on others.
But, OFC, both WindowMaker and Mac OSX come from the same NeXT grandaddy...
If by "others" you mean Mac, okay, but KDE and some other Linux desktops are at least as good as Windows at this out of the box, and much more customisable.
There are a bunch of third party tools you can use though, [AltTab](1) is free and tries to replicate windows experience on Mac. [Raycast](2) has a Switch Windows command which also allows direct access to any window via the keyboard (bind to alt+tab if you like) amongst many other features.
[1] https://alt-tab-macos.netlify.app/ [2] https://www.raycast.com/
I've switched to abduco for persistance and use neovim for window management (both vim and neovim have a built in terminal emulator). Using vim keybindings for managing windows and tabs is more natural, I can copy/paster just normally and you even get some perks like `gf` to quickly open a filepath under the cursor.
I liked the fact I didn't need to set anything up for Zellij and could gradually add stuff
I dont see this as an issue though. Terminals are pretty much a solved problem, they dont need any new features. IMO it makes more sense to spend effort on improving tmux<->terminal interop rather than adding fancy graphics protocols that we dont actually need.
so no, terminals are not a solved problem.
i can select a column in tmux too, using tmux commands, and then it's the same problem. i can't use that selection outside of tmux.
i simply want the GUI to be aware that there are multiple columns in the terminal and let me select text within one using the mouse and then copy that to a different window/app.
A correctly compiled Vim will make the two X clipboards (“selections”) available as registers * (“primary”, i.e. the current selection, pasteable with the middle mouse button) and + (“secondary”, accessed with Ctrl-X/C/V) for both reading and writing. (I believe these are synonyms in graphical environments that don’t have two clipboards.) You can make one of them the default by adding
set clipboard=unnamed
set clipboard=unnamedplus
> i can select a column in tmux too, using tmux commands, and [...] i can't use that selection outside of tmux.
If you’re using Wayland on Linux, install wl-clipboard and put
set-option -s copy-command wl-copy
[1] https://github.com/tmux/tmux/wiki/Clipboard#the-set-clipboar...
> Goals … Do not reimplement tmux and his comrades.
( From https://st.suckless.org/goals/ )
I use it a bit with remote connections, but tmux is basically my IDE for development. I have the backtick mapped as my prefix and I hope between terminals and Neovim, and I am considerably less productive when I don’t have this setup.
Sometimes, the old ways are better. A lot of times, actually.
This is of course true of every other terminal emulator as well, and indeed it's not only colours that are incorrect. Function and editing keys get recognized incorrectly; REP can get used where it does not work; and even simple relative cursor motions can be done wrongly.
TERM and the ideas incorporated into terminfo/termcap are inherent in the way that terminal devices work on Unices and Linux-based operating systems. That there are different terminals and terminal emulators not all speaking exactly the same protocol is also an unavoidable reality.
Setting TERM properly isn't some tmux-specific problem.
Also im not sure whether the scolling problem is actually tmux fault. Tmux uses the alternate screen buffer, the alternate screen buffer is activated using the smcup/rmcup terminfo capabilities, whose semantics actually say that it "fixes" the window viewport in-place so absolute cursor movement has a known zero position. In this state, any native scrolling attempt should have no effect, and the keypress/scroll wheel events should be forwarded to tmux directly.
For some reason, every other terminal emulator still allows local scrolling in the alternate screen, which kinda breaks the semantics of smcup/rmcup and easy scrolling in tmux, too.
I've tried
Wezterm Ghoatty Ptyxis
First two had some frequent crushes, ptyxis is quiet reliable, but I felt it consumes too much memory for a terminal. But I feel it's a good terminal.
Though I wish I could get rid of the headerbar
Nevertheless, yeah, I meant crashing, All these years of gnome terminal, Tilix I never had them crashing.
In the case of TMUX, it can be a bit annoying because it's not immediately apparent _why_ things look wonky. But I'm not sure what the solution is. Default to 256 colors?
Correct, but it's another layer to deal with. There are `tmux` specific TERMs that should be used which sit on top of your terminal emulator TERM. This was my point: you have another layer that you need to be aware of when using tmux and when debugging.
Just look at the top of tmux's FAQ:
https://github.com/tmux/tmux/wiki/FAQ
> PLEASE NOTE: most display problems are due to incorrect TERM! Before reporting problems make SURE that TERM settings are correct inside and outside tmux.
> Inside tmux TERM must be "screen", "tmux" or similar (such as "tmux-256color"). Don't bother reporting problems where it isn't!
> Outside, it should match your terminal: particularly, use "rxvt" for rxvt and derivatives.
So I used Claude Code to build a little el tool called Tmux-cli, which gives a convenient way to have CC (or any CLI coding agent for that matter) spawn a Tmux Pane, launch a script there, and actually interact with it.
So it’s like Playwright/Puppeteer for the terminal.
You can get it via
uv tool install claude-code-tools
There are some interesting possibilities this enables:
Let CC autonomously test interactive CLI scripts, without me having to intervene and point out errors.
Have the CLI coding agent launch UI from another pane and then use Puppeteer MCP to test from a browser.
Let CC launch a cli script with a debugger enabled (e.g. Pdb) and set breakpoints etc — for token-efficient code understanding, debugging and explaining.
Let the CLI coding agent spawn and drive another instance of the same or other CLI coding agent, AND interact with it. Note this is way better than CC sub-agents which are “spawn and let go” black-boxes.
I wonder if the discussed Tmux alternatives enable building this type of tool.
Very cool ideas in this thread.
I mean, a tty is just a file descriptor... there have been script(1), expect(1) and chat(8) since the 80ies. tmux is not really necessary.
Bringing another terminal multiplexer isn't an alternative. In my agent, I use pseudo-tty without any tmuxes/screens.
I used it in a previous job to automate configuring thousands of network devices
I tell Claude to use the existing tmux CLI to send-keys, capture-pane, etc. and it works flawlessly. Literally just "never use the Bash tool, run all commands in tmux sessions" and it knows what to do from there.
In case anyone was curious, screen can do this too with the command "stuff" (read it as the verb like "stuffing something into a box").
Could I have kitty send each line it receives to an external tool, say via HTTP?
I want to make a custom frontend to claude code, or any other CLI tool, and an obvious easy frontend is a web tool that communicates over HTTP, so getting claude wrapped in a HTTP control system seems like a good starting point.
I'm interested in whether things like "tmux capture-pane" which strips characters come from Kitty as well? Do I need to be cautious of control characters?
This is a feature for me. Because less and less applications bother supporting termcap, this way some applications can still work on my VT520.
I don't really care what the kitty dev thinks anyway. He's entitled to his opinion but for me tmux is way more important. Also I think alacritty is better (though I generally just use Konsole).
As a user I only care about what works well for me, not what's architecturally the most elegant solution.
I've been on the lookout partly just to see whether this works properly with a genuine VT525:
* https://jdebp.uk/Softwares/nosh/guide/commands/console-termi...
Yes, should tmux ever go away, there's another option for transliterating terminal output of applications that just expect all of the modern stuff with AIXTerm's 16 colours and alternate screen buffers and mouse sequences and whatnot and do not check TERM properly. (-:
diff --git a/tty.c b/tty.c
index 359dc13..f98c9c4 100644
--- a/tty.c
+++ b/tty.c
@@ -319,8 +319,8 @@ tty_start_tty(struct tty *tty)
event_add(&tty->event_in, NULL);
memcpy(&tio, &tty->tio, sizeof tio);
- tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP);
- tio.c_iflag |= IGNBRK;
+ tio.c_iflag &= ~(IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP);
+ tio.c_iflag |= IXON|IGNBRK;
tio.c_oflag &= ~(OPOST|ONLCR|OCRNL|ONLRET);
tio.c_lflag &= ~(IEXTEN|ICANON|ECHO|ECHOE|ECHONL|ECHOCTL|ECHOPRT|
ECHOKE|ISIG);
stty -iutf8 ixon
export LANG=en_US
I've also hacked up support for storing tmux window contents in different pages of VT memory, so you can switch windows instantly without waiting for full screen redraws. It's a bit rough around the edges (doesn't handle split windows very well, for example), but it's enough of a quality-of-life improvement that I use it anyway. It's a bit long for a comment, but I can post it somewhere if you're interested.
Feel free to email me if you want more information about my setup.
Can I ask why? It starts slower (has a significant lag on old hardware), has way less useful features (like tabs), has the same responsiveness, and loses in benchmarks (for what they're worth). I see no reason to use it when kitty/ghostty/konsole/foot exist (depending on one's preferences), but people obviously do.
With this in my `~/.ssh/config`, I can just type `ssh tmux` to get back to my remote dev box whenever I wake my computer or change connections.
Host tmux
HostName 1.2.3.4
IdentityFile ~/.ssh/etc.etc.etc
RequestTTY force
RemoteCommand tmux -CC new -A -s 0
So you're saying you're a masochist
Host tmux
HostName 1.2.3.4
IdentityFile ~/.ssh/etc.etc.etc
RequestTTY force
RemoteCommand screen -dR
unbind-key C-b
set -g prefix C-Space
bind-key C-Space send-prefix
GNU screen was released in 1987.
tmux was created in 2007.
I've used mosh a lot but it's just interesting to note it's in the same category as screen and tmux
I basically don't use ssh at all any more for interactive sessions, because I'm sick of a few lost packets on wifi or a weak cell signal dropping my connections and forcing me to start over.
Tmux, I used to use and eventually abandoned. I decided I didn't need two keyboard-based window managers (I use Spectacle on Mac) and the one that was only for shells was the one that could go. I have replaced it with nothing, so far, aside from that I just open more Terminal.app windows now (I also used to use iTerm2, for years, until it dawned on me that I was using exactly nothing in it that's not also provided by Terminal.app, and the latter's got better input latency, so I was suffering an extra installed program and slightly less responsive typing for no reason at all)
I leave with the laptop, return days later, and perform no manual intervention to reconnect. It's absolutely brilliant.
alias looptmux='while true; do ssh tmux; sleep 2; done' autossh -M0 tmuxNote: that Terminator I linked is a re-boot (I'll be back) so, I might give it another go as well.
The author of this feature also ported it to the Windows Terminal.
Besides, Chrome OS’s built in terminal also has tmux integration.
Would love for examples using Windows Terminal as well.
I wanted it to be better, and might go back if I could figure out the font issues, but I just don't have the time right now.
Interesting, I've been using exactly that combination for ... as long as tmux and iTerm2 have been around?
I am not aware of any color or font issues. What am I missing?
Does everything still go "through" tmux (so parsing etc. is still done twice), or does iTerm handle most of the rendering and just delegate scrollback storage/session persistence to tmux? The latter seems like the best of both worlds.
I am a former Kitty user and current Ghostty user and hope Ghostty stays basic and good.
Edit: It appears to be related to iterm2's tmux integration. Neat.
set -s copy-command 'xsel -i'
The session persistence thing is still best solved with tmux, however, I don't ever need this. Nohup is sufficient for long running commands where my ssh might fail. I don't really find myself sshing into a machine and then setting loads of env vars that I need to persist.
kovid is talking about how tmux gets in the way of terminals adding new features. i agree with that, but what about the features that tmux offers that i have yet to see in any gui terminal. (multiple sessions. the ability to connect to the same session from multiple terminals. scriptability, including sending characters into a terminal. splitting windows into multiple panes...)
can kitty do any of those? if you want to add features to the terminal, then you have to content that tmux does as well, and maybe tmux features are more interesting to me than kittys. so if you want to win me over, then you have to actually implement some of the features of tmux that i use.
(watching the interview, it looks like kitty does indeed implement some of tmux features, because interestingly the interviewer asks just the right questions. but i need to look for a more comprehensive introduction to see how kitty can replace tmux locally.)
first impression: dark background. no good. i want light. no gui to change. now where is that theme setting? ah, here: https://wezterm.org/config/appearance.html there are 1000 color schemes available! wut? ok, this seems to be all i am looking for: https://wezterm.org/config/lua/wezterm.gui/get_appearance.ht... gee, that's a lot of code for a single setting.
ok, that's better. now let's explore how wezterm handles sessions and windows/tabs.
it seems sessions would be domains, and so for a bunch of local sessions i need to configure some unix domains: https://wezterm.org/multiplexing.html#unix-domains
there is more about sessions here: https://wezterm.org/recipes/workspaces.html but it's all very abstract.
and where does this stuff go? ah, here: https://wezterm.org/config/files.html
turns out that the config example for the color scheme conflicts with setting other config values. i need
config.color_scheme = ...
return config
not
return { color_scheme = ... }
and finally, how do i switch sessions or tabs? no word about that on the multiplex page. or elsewhere.
fortunately, i found this article which describe an elaborate setup to make wezterm behave somewhat like tmux, with familiar keybindings. maybe i can get this to work: https://mwop.net/blog/2024-07-04-how-i-use-wezterm.html
oh, one last issue: there are no resize handles, or a titlebar, although according to the descriptions they should be there. where did they go?
1. zoom-pane (temporarily make one pane be the only pane) (also can someone please add this to vscode!)
2. keybindings to navigate focus between panes according to their layout positions
3. ability for another process to programmatically change which terminal window has focus, and window naming
I think that's it. Could probably hack most/all of that together with hammerspoon I guess. I don't use it for persistence, and I certainly don't like the scrollback UX. It has got in the way from time to time, principally with its slow adoption of hyperlinks. But I'm general it's been a huge win for years.
One cool feature of tmux is its ability to send keys. I did that a few months ago when I was revamping my dotfiles. I kept changing aliases and other shell files and wanted to source those files in dozens of panes at once and also reload neovim when I changed certain config files.
The above was pretty easy to pull off using a combo of tmux's built-in commands and a shell script. I made a post and video about that here: https://nickjanetakis.com/blog/running-commands-in-all-tmux-...
It's also nice to be able to re-connect and be able to resume a session without having to reopen many terminals, which you would lose with the lack of window management.
I went back to tmux and basic terminal because it works everywhere, and composing tools is just more durable overall.
I have similar setups for various projetcts and do not need to manually start services, tools, whatnot. With `mx projectx` everything is started within seconds.
And navigating panes and windows is super easy with the proper shortcuts (opt+h,j,k,l), even across tmux and nvim.
Why would I give up on that?
Then it is a pragmatic decision, using tmux you get to use the ecosystem of things like tmuxinator which explicitly target tmux to get a known number of terminal features like splits. What I learn from the OP, is that there are technical reasons that tmux is not a "good design" - like Kovid's comments on how it constrains innovation in terminal designs - which might lead someone to consider, what actually does tmux do and could my workflow be implemented otherwise?
It might be a bunch of unixy hacks and tricks (as another commenter here said) but it can work. I'd imagine recreating something like tmuxinator would be hard though, but it could also be interesting, like having arbitrary GUI programs configured to appear in "splits" using tiling integrated seamlessly within the terminals. But yeah, if the workflow is already set up and serviceable and supported with a community, using tmux, then I'd just keep using it.
1. Having to zoom a window before copying multiple lines of text (Kovid brought this up in the interview that was mentioned in this article)
2. The weirdness of copying text from the scrollback buffer into the clipboard
I've tried so many things for the second one over the years. I think I have it working okay-ish these days. But there are still plenty of times that I say, "aw screw it", and literally use the terminal's copy command.
Every other solution to my multi-terminal workflow have been worse though! i3/bspwm with multiple terminals were okay. It was just hard to have "projects". I'd have to visit each terminal and switch to the proper directory, launch servers/docker-compose/etc.
Zellij felt like too much "hopping out into manipulation mode, manipulating, then hopping back into work mode". Those milleseconds were enough to halt my flowstate.
Single terminal with built-in tabs/splits felt clunky as I couldn't get the keyboard shortcuts into muscle memory (perhaps more time would help)
The rest the Operating system applications can probably do better anyway. VLC, MPV, Apple Preview IrfanView etc.
That's why I love Alacritty, no fuss, no overcomplication. The basics, fast and stable.
But I also take issue with statements like "terminal multiplexers are a bad idea, do not use them, if at all possible" (from the kitty FAQ and the YouTube video linked in the article). Tmux solves a number of real problems for me that Kitty doesn't. Kitty also seems to be moving in a direction that I am not interested in. It's tied to a windowing system when I want a terminal that I can use headless. Even with the hacky workarounds the article mentions, it doesn't really support session persistence when I use this feature of tmux weekly. It introduces a lot of features that are likely to lead to visual noise when the constraints of text-only are one of the main reasons I like terminals (personally I don't want images in my terminal, full stop).
Now, all of this is fine. It's the other statement, "[tmux acts] as a drag on the ecosystem as a whole, making it very hard to get any new features," that causes it all to rub me the wrong way. The only reason you feel like tmux acts like a drag is because there are users like me who won't switch to something like Kitty if it doesn't support tmux. So don't worry about us. Build a new thing that is not backwards compatible and live with the fact that many people won't use it. If you really want to drive the ecosystem forward as a whole, be less condescending about real use-cases that bring benefit to real users.
To be clear (because text is a limited medium), I'm not grumpy, angry, or against Kitty because of this. But I am dismissive.
And what about mouse select to copy/paste? It works most of the time, but
sometimes tmux gets ignored and I'm selecting across splits which makes the
thing I'm copying impossible to grab without bailing.
Otherwise complaining about tmux and talking about hacky workaround alternatives is a bit like complaining about the internet and advocating for the telegraph as a hacky alternative because you don't like writing your own HTTP requests by hand and morse code is so much simpler.
Having said that, if really all you want is pane splits / window management, lots of terminals have their own solutions for this. Guake is a good one.
disclaimer: I use Guake and still prefer to just use tmux (byobu) from Guake
I did come up with Ghostty bindings to replicate my tmux settings if it helps anyone (my tmux leader is ctrl + space):
# clear default bindings + add paste back
keybind=clear
keybind=super+v=paste_from_clipboard
# navigate panes
keybind=ctrl+h=goto_split:left
keybind=ctrl+j=goto_split:bottom
keybind=ctrl+k=goto_split:top
keybind=ctrl+l=goto_split:right
keybind=ctrl+space>shift+apostrophe=new_split:down
keybind=ctrl+space>shift+five=new_split:right
keybind=ctrl+space>space=equalize_splits
keybind=ctrl+space>z=toggle_split_zoom
# navigate tabs
keybind=ctrl+space>c=new_tab
keybind=ctrl+space>one=goto_tab:1
...
keybind=ctrl+space>zero=goto_tab:10So, if your multiplexer lacks support for certain features, it will limit functionality in advanced terminals like Kitty or Ghostty.
I have actually seen this before, in the very fun but silly and not-particularly-useful edex-ui thing. (great way to impress people who don't know, but like, if you type your password in it it literally shows the keystrokes)
But I really want Vim to color properly in it, can anyone give me the right solution?
It’s just too bad I suffer from a lack of common sense and insistence on trying to believe that all archaic terminal text based tools are better than anything else. I’m a developer and developers have insight on the best UI and we know that terminals are better than anything in the known universe. If you use a mouse you’re an ass hole.
Useful debate on the merits of anything is a pointless endeavor because all varying opinions are valid. There is no best, better or worse… just everyone’s freedom of opinions.
In my opinion eating lead is good for you and using a mouse and clicking on tabs hinders my efficiency by 300 percent. That’s my opinion! And it’s valid! I am valid!
Tmux is good when you have no gui.
But all this endless getting square pegs to fit in a round hole is what causes the snarks. Like you want to draw windows? Let’s use terminal characters instead of lines! Makes perfect sense.
I find it incredulous that a lecture had to get this guy to realize what’s wrong with tmux and he still doesn’t see that this problem can be avoided by using a gui. He still goes for terminal abstractions.
GUI is an obvious solution. But this guy is blind.
Sorry but no, really no.
Windows:
- Has two ways of swapping between windows, taking up 2/3 of my modifier keys for use with Tab
- Loves to offset windows by one pixel and resize my taskbar
- Irrevocably moves things around if I disconnect a monitor
- Flashes taskbar icons constantly, like a particularly badly behaved terminal bell
and Mac:
- Leaves zombie processes in the cmd-tab list
- Is philosophically incompatible with any kind of fullscreen workflow.
Both have:
- Slow animations for basic windowing
- Only a few tiling options
- Minimal configurability...
- ...which doesn't matter anyway, because if someone at HQ gets bored, you're getting a UI interface redesign that's incompatible with your current workflow
- An approach to tab dragging that induces seizuring windows, because things are just too slow and fickle
- The ability for anything to steal my focus, mid-typing
But what's most damning of all is that both have a wealth of popular tools written and used by people trying to wrangle them into something useable.
There is nothing I could do to make them as fast to use as my tmux based workflow, simply because they do not work quickly enough for the keypresses I'm entering and don't even appear to be deterministic.
So for some reason a terminal app where you can't even draw a proper line vertically across the screen... somehow the people who make apps for terminal are geniuses in making windowing UIs, more genius then people who want to work in pixels. I don't understand why.
And these complete geniuses are like, NO! I don't want to work with pixels. I want to use ascii characters to draw stuff that ONLY looks sort of like boxes, because that's the smarter thing to do!
And don't get me started on config files. What's better, a menu where I'm presented with all my options? Or a freaking config file where none of the options are presented and I have to look it up in a man page and then if I make a typo often it doesn't tell me there's a problem.
And likely you aren't even using that terminal app in a proper terminal. You're emulating a terminal underneath a GUI which is a huge performance penalty. Modern OS's present to you an advanced interface, but you're too elite to use it, so you EMULATE a primitive interface underneath the advanced interface.
Bro use linux and uninstall gnome or KDE. Throw that mouse into the trash. That's the common sense future of UI according to you?
oh the irony. because that is what wezterm and kitty make me go through. i'll have a report soon.
EDIT: here is the report: https://news.ycombinator.com/item?id=44762241
that wezterm config file is a monster. all that, just to have tmux like functionality. well, at least it is possible. that's a massive step forward.
You get neither
thank you. that helps.
All done in GUIs and done better
could be done, and i agree. but i have yet to find a terminal GUI that actually does.
tmux has a great and useful TUI. all the terminals i have tried so far, have a very minimal GUI. they have tabs, and some have panes that's about it. tmux works out of the box without any configuration at all. i can just build up my sessions interactively. i evaluated kitty a year ago, and i am testing wezterm now. neither are usable without having to manually write an elaborate config file, and neither include all the features that tmux has.
i would love to find a GUI terminal to replace tmux. but there isn't one yet. at least it looks like both wezterm and kitty are working on it. so maybe in a year or two there will be something that can actually compete with tmux. but until then it's just a wish.
The below is fixed (https://github.com/shell-pool/shpool/pull/213/files) upstream already, but is pending a release.
I never heard of shpool, so just tried it. shpool completely breaks my PROMPT_COMMAND because it assumes that each word (in the shell sense) is a separate command. My PROMPT_COMMAND included "history -a" thus causing it to run "history" and "-a" on every prompt, making things quite unusable.
It's quite maddening because all they had to do was write a lot less code to fix it:
eval "${SHPOOL__OLD_PROMPT_COMMAND}"
for prompt_hook in ${SHPOOL__OLD_PROMPT_COMMAND};
do
${prompt_hook};
done;If there's a better way, I'm open to it. As of right now Claude can't vibe code me a script that opens two ghostty tabs, so tmux it is
My workflow is project oriented, and I have to juggle multiple projects. So I wrote a small script to let me quickly either attach to an existing dtach session for a project by name, or to start a dtach+nvim session for a project.
Also included some fun wildcarding, so I didn't have to type the full name of the project out, could just type some letters and hit enter.
https://github.com/jauntywunderkind/dtachment
I don't see change as likely, but it does strike me as absurd that although I had gotten rid of tmux as a redundant window management system, I still had both the OS and nvim's window management going. The author talks about how things would work over ssh, but ideally to me, I could ssh in, forward some ports, and start some new terminal emulators that open multiple nvim clients that attach to a persistent perhaps headless nvim session.
The primary usecase I've had for it is I can kick off 1 or multiple long running jobs, exit, and then come back later and checkout the various stdout logs to see how it worked.
Could I accomplish the same thing with a bunch of stdout pipes, disown, fg, ctrl-z, etc? Sure. However, tmux makes it really easy to do that and then quickly switch around sessions to see how things are going.
In the simplest workflow, it looks like this
tmux
longcommand()
ctrl + B D
tmux -a
> In summary: multiplexers add unnecessary overhead, suffer from a complexity cascade, because they actually have to translate escape codes, modifying them in hackish ways to get them to work with their concepts of windows/sessions.
What does that have to do with you using tmux? You're not the one maintaining tmux's codebase.
This problem is in no way unique to tmux. You have the same problem with any terminal app that takes over drawing, eg vim. That said it is also easy enough to fix.
The solution is OSC52, a terminal escape sequence that the emulator can use to interact with the system clipboard (kitty, alacritty, iterm2 all support this). The first step is to get you a script that writes out data in that protocol. Its easy enough:
#!/usr/bin/env python3
import os, base64, sys
clip = base64.b64encode(sys.stdin.buffer.read())
for pid in (os.getpid(), os.getppid()): # so that osc52-copy can be invoked by processes that themselves do not have a tty.
cty = f"/proc/{pid}/fd/1"
try:
fd = os.open(cty, os.O_WRONLY)
if os.isatty(fd):
os.write(fd, b'\x1b]52;c;') # the actual escape sequence
os.write(fd, clip)
os.write(fd, b'\a')
break
except:
continue
finally:
os.close(fd)
else:
raise SystemExit(f"no tty")
$ grep my_thing < some.txt | osc52-copy
And whatever got into osc52 is now on your system clipboard.
Tmux (set -g clipboard on) and nvim (unset clipboard) both have native osc52 support, and the script above can be used to integrate other places.
I use it to copy from remote system when I'm in nvim (`"+y`).
Here are a couple links that relate to tmux and nvim.
- tmux: https://github.com/tmux/tmux/wiki/Clipboard
- nvim: https://neovim.io/doc/user/provider.html#clipboard-osc52
Yes, it's true that an application that can read system clipboard content may scrape a password, but literally any application running in the terminal can read private keys out of your .ssh folder.
With some heavy reading and a bit of experimentation, you can usually get this working, though.
Eh, lots of people use tools for ages without digging too deep.
Also, tmux new-window does wonders with software spawned from sfeed, sacc and who knows how many TUI/CLI tools.
You open your RSS feed list with sfeed, read the whole page with C under 'less', and if there are images, you can spawn Links in another page with 'o'.
But, I am not an uber-elite-geek and Zellij is a good enough compromise to me.
It gives me the things I am too lazy to solve by myself like tmux, with a lot less pain points.
* Scrolling on TTY (Linux itself doesn’t support this for some years)
* Window-Tabs on TTY, Wayland, SSH
* Sessions
* Copy/Paste
Would love some good C developers helping the Screen people.
Press "<Enter>~." into your ssh window.
Do you think ssh isn't interpreting escape codes either for some reason?
You can make tmux's OS window title and its internal window titles be whatever you want:
Add "set -g set-titles" to ~/.tmux.conf. To test without changing the config, type `^B : set -g set-titles`, and to restore it back to default, `^B : set -gu set-titles`. This will be useful but overly verbose. It can be configured further. For example, `set -g set-titles-string "tmux | #{pane_title}"` will make it contain the title set by the shell (for PS1, I just make it set the current directory with `\w` or `\W`).
Then, to make tmux's window titles (so, what will show up in the "window list") also be named after the current directory, you can use `set -g automatic-rename-format "#{pane_title}"`.
1. Log in to the physical server.
2. Start a named tmux session.
3. Run the Minecraft start script (log messages start populating)
4. Ctrl + b ... d
Now, whenever I need to do something with the server, I just attach back to the session and do it.
First step, reimplementing the (arguably) one essential thing tmux provides, i.e., persistence: all tools have "varying degrees of success" and "are buggy". Scrollback? In tmux you "have to learn the tmux way", with the alternatives you might have it if you're lucky.
I went into the post with an open mind but I don't think I will be ditching tmux anytime soon...
znpy•16h ago
I'm still a gnu screen guy, but for me the trade-off is still in favour of screen/tmux.