- You're connected to a remote host and you don't want an unexpected network issue to kill your session

- You want to be able to periodically check on the status of something on a remote host but don't feel like keeping the connection open all the time

- You want to connect to the same session from different clients

- You may need to restart you graphical session and don't want that to kill your terminal session

A really simple way you could get this working is what abduco and detach do: the demon just blindly shuttles input and output between the client tty and the virtual tty that the interactive process is running in. However, when you reconnect to an existing session, you get no context, because the server doesn't know what it would need to tell the client for it to reassemble the tty state.

In order for that to be possible, the daemon would need to keep track of the terminal state internally. It's really annoying that that's necessary because now your actual terminal emulator isn't directly communicating with the process it's displaying, and you won't be able to access any features of your terminal that the daemon doesn't support.

But once you already have this background process that's keeping track of terminal state, you might as well build in other features that would require that, like window management, otherwise people who want those features will end up having yet another layer of terminal. If you don't want those features, you can pretend they're not there.

It's sort of like being able to RDP into the machine you were working on except it's text-based.

So you can have tabs, splits, sessions, etc, all scriptable. Eg if I hit F1 in the shell I automatically get the command’s man page alongside the interactive shell.

I’ve also used it on occasions where I’ve needed to pair program with someone on a poor internet connection. We’d SSH into a common area and share a tmux session while chatting on a regular phone call. Thus no bandwidth heavy video conferencing.

It’s also been handy back before I worked fully remotely, I’d have a dedicated desktop running tmux and when I got home I would VPN into the office and resume the tmux session so I could resume where I left off.

Sure, you can do everything in a WM or DE, but I use Linux and macOS and it's nice to have the same configuration, keybindings and environment everywhere. I also find tmux more customizable than Gnome Terminal and easier to setup than st or urxvt.

Also - for long running processes, you can run stuff in a tmux session, go to bed, and wake up hours later and see exactly what happened. You can make the scrollback buffer as big as you want. My scrollback history is 50k lines, and that's totally fine. Of course the history is searchable with vim commands which is also nice.

I remember getting into Unix just a little before the time tmux came onto scene as the modern alternative to screen, and being in awe of all the people who had used screen long enough to have a list of things that could be modernised about it.

Now tmux is in that position!

[1]: https://github.com/martanne/dvtm

    rpick() {
        session=$(for i in $(tmux list-sessions -F '#S'); do
            echo -e -n "$i\t"; { { tmux capture-pane -p -t "$i" | tr '\n' ' '; } || true; }
            echo
        done | fzf --exact --reverse | cut -f 1)
        if [[ "$session" != "" ]]; then
            tmux attach -t "$session"
        fi
    }

https://help.ubuntu.com/community/Byobu

I'm sure there are newer/better? tools someone might recommend here too.

I use zoxide now, it's slightly faster.

Essentially you get all tmux functionality on the remote but with the local ergonomics you're already used to.

The home page also has some issues with elements clipping/overlaying and not registering clicks.

I say weirdly unfriendly because the graphic design is very $CURRENT_YEAR, which is usually designed mobile-first (since that’s where most of the traffic is these days). But the author clearly spends more time on the desktop (the article _is_ about tmux) and didnt check how it performs on mobile.

If it is just a safari issue I’m sympathetic. Testing for safari is a nightmare if you don’t have Apple hardware available.

Seems like a transcoding error for certain devices only then, if nobody else noticed it.

Unrelated, but it was completely impossible for me to put the video on full screen. It seems like the site did something with the scroll that prevented me from scrolling horizontally to click the full screen button.

One for my blog, podcast, 2 side projects, contract work, etc.. I usually have 6-10 sessions. Although I don't use fzf to search through them. The built in leader+s key makes finding and jumping between sessions painless, you also get the benefit of being able to see a preview of what's in the session.

  > sendmsg(5, {..., msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[7]}], msg_controllen=24, msg_flags=0}, 0) = 16

  > open terminal failed: not a terminal

problem is that it then doesn't work for local sessions. so you run it locally, which gives you local sessions and window management, but then all remote connections have to be via mosh -or- you mosh into the datacenter which is good for accessing infra, but leaves you having to run a separate instance for local work.

> the local tmux then remembers history and allows looking up commands on the remote shell, that would be huge.