Replacing tmux in my dev workflow

As someone who uses Linux on all my personal machines but has usually had to use a MacBook for work, tmux is also pretty useful as a platform- independent tool for me to reuse the same workflow without needing to worry about differences between the two. I use Alacritty on Linux, but when I've tried using it on MacOS, there have things that don't seem to work for me out of the box the same way they do in Linux (which I'm struggling to remember exactly at the moment, but I think one of them might have been the setting to have the window maximized on startup). Rather than spend time trying to tinker around on an operating system that I don't have any particular desire to use outside of just getting my work done, it's pretty nice to be able to use tmux on iTerm to get basically the same experience I do on Linux. From that perspective, having something like an entirely independent way of scrolling back in a session is a feature to me, not an annoyance.

A lot of these arguments against tmux seem like they're more relevant to someone developing a terminal rather than using it. It's fine for people working on their own terminals to decide they don't care to support it, but I don't really find the arguments convincing as something I should care about, and I'd personally just switch to another terminal with better support for it rather than stop using it.

I use a combination of mosh and screen for this. I only need to type something to get my session back, after a reboot. Changing networks or putting my laptop to sleep for days doesn't drop my sessions: https://www.grepular.com/Immortal_SSH_Sessions

Wow, I've tried tmux like a hundred times and could never learn to like it, falling back to screen and promising to myself - never again. I'm going to break my promise to try this.

I ran into so many little annoying color and font issues with vim, tmux and iTerm2 that I gave up on tmux (for local work). What small benefit I got from tmux on my local machine (basically surviving updates and a little more session persistence) I rarely miss.

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.

Does any Linux terminal have a comparable integration? I'm still using GNU Screen but willing to give tmux another shot.

I've just now learned about tmux's control mode. Can you explain what that tmux -CC command does? I use `ssh -t <host> tmux attach -d` from bash history to (re)establish my remote tmux session. `new -A -s 0` would do the about same thing, I just don't see how -CC is supposed to work here.

Edit: It appears to be related to iterm2's tmux integration. Neat.

Wow, I was wondering if e.g. Ghostty could implement something like this but that's cool it's already proven out.

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.

Would mosh stop you from having to reconnect to SSH at least after wake? You'd still need to reestablish a mosh connection after rebooting.

> I don't mind dealing with wonky copy and paste once in a while.

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 am tired of seeing people creating problems out of nowhere. The reasons author gave are stupid and I am gonna question his "7+ years" of tmux usage

> and found out that one of the nifty features is that it is scriptable, I.e allows programmatically sending keystrokes to a specific pane

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").

Yup, another fun thing to do w/ this: let Claude Code talk to and control Gemini CLI, OpenCode, other CC instances, etc. in interactive mode! A different flavor of subagent. :)

Do you find the tmux-cli wrapper to improve results?

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.

If you're interested in doing similar things but with a terminal, the Kitty remote control mechanism is pretty cool: https://sw.kovidgoyal.net/kitty/remote-control/

> So it’s like Playwright/Puppeteer for the terminal

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.

Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.

Yet the author incorrectly blames it on tmux, which gives the article a bad taste.

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 agree. It's also true of nearly any program. If you do not set its configuration properly, it may not work as expected.

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?

> Setting TERM properly isn't some tmux-specific problem.

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.

You are very lucky to have a VT520. I have been idly on the look-out for a 525 for years, but not only are they inordinately expensive, the people selling them are not on the same continent as I am (and probably don't have my country's version of the LK).

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. (-:

My VT420 doesn't support hardware flow control, but software flow control does not play nice with many modern terminal applications. GNU Screen provides an extremely effective workaround, plus its other features. I've used tmux a lot on modern terminal emulators, but it seems to lack this important feature for vintage terminals. Glad that tmux solves your problems with broken apps that don't support termcap or terminfo.

> I think alacritty is better

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.

That is something I have strived for recently, to use all the great window management features of my window manager of choice instead of browser tabs or lots of terminal tabs running tmux. If that didn't work well I guess it would have been a good sign that I need a better window manager. Even went back to use bookmarks instead of leaving hundreds of tabs open and having a bookmark bar instead of a tab bar is not bad at all.

> I view "you might not need tmux" in the same way as "you might not need browser tabs".

A big difference is that I can move two browser tabs into separate windows, or from separate windows into the same.

The same is actually tree of top-level windows if your window manager can group windows into tabs.

tmux tabs lack this flexibility.

I have come to believe that tab management is really the job of the window manager not individual apps. My window manager allows me to tile windows, or create tabs out of overlapping windows. The tabs can be from the same app or even different ones.

My tmux config has clickable tabs in one terminal.

MS Windows has excellent multi window management with Alt Tab Win Tab etc. Far superior to others.

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”

But many terminals have tabs so if all you desire is more than one terminal open but not multiple ui windows there are other options. VSCode for instance!

Anyone calling anything an anti-pattern without evidence always sounds to me like 'I don't like how you do this, but I need to find a more cerebral way of describing that so I don't sound like a child.'

it may become an anti pattern once kitty implements all the features tmux has. it appears wezterm did that. if that's the goal, then i am all for it.

tmux capture-pane - | vim - is a bit more comfortable than the mouse scroll wheel.

I'd say suckless and Kitty are pretty much the polar opposites of development.

I used Kitty for a while. I was impressed that I could recreate my tmux config pretty closely.

I went back to tmux and basic terminal because it works everywhere, and composing tools is just more durable overall.

At one point I was wondering if there was a preexisting protocol for a character-based framebuffer of some sort, that we could then use to slice the problem in a different way: a framebuffer multipliexer running terminal emulators inside it instead of a terminal multiplexer emulating multiple terminals into a framebuffer and then translating it back into terminal controls for the parent.

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.)

> It more just argues than tmux is a pita on the terminal ecosystem which I’m sure is true.

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.

weztern has a really strong solution in this space when you use it with its multiplexing server on the remote end.

It's more like you don't need to use a webpage that offers tabs using iframes because the browser natively has tabs that you could be using instead.

Having native scroll back should be possible if you hack tmux and a terminal emulator.