Comment by boredtofears
3 days ago
To throw gasoline on the fire: this how I’ve always felt about tmux. Why use an incomplete in terminal windowing system when I can just have multiple terminal windows open managed by the superior OS window system.
(That said I know tmux is sometimes the only option and then it makes sense to me)
I tend to run my tmux session for months at a time on my office workstation. When I remote in to that computer, I can type ‘tmux attach’ and all my context is there. I might have four long arc dev projects running at once, and my planning system, all within those windows.
On our datacentre servers, I also have tmux running. It is fast to connect to these hosts, attach tmux and continue from where I left off.
Another use case: it is common for corporates to require devs to use windows desktops, but to then give them a headless linux host in a datacentre for development work. Here, you use putty to connect to the linux host, fullscreen it, run tmux. On your desktop you have outlook and office and putty and a browser and no dev tools. You can do all your planning and dev work on the linux host, using your favourite ten thousand hours text editor and building your own tools, and this becomes your hub. You lose awareness that you are connected to this from a locked down windows host. Corporate security reboots your windows host for patching several nights in a row, and it does not cause you any hassle because your work context is in the tmux session on another host.
The difference is that tmux, with all its state, typically runs on a remote system. The graphical equivalent would be a VNC &c. session, assuming that the remote machine has the prerequisites for that (which is a pretty big ask).
tmux (and screen) are incredible assets for remote sessions, both for continuity across dropped shells and multi-shell activities when the connection process is tedious (multiple jumphosts, proxies, etc.)
I've fallen out of using it, but for a while I was using dtach to do similar without the virtual terminal multiplexing. Much much more direct.
I'd just run a vim session. If I needed terminals, they were in my vim! Even wrote a short shell-script to automate creating or re-attaching to a project specific vim session. https://github.com/jauntywunderkind/dtachment
Haven't looked into it, but I'm love a deeper nvim + atuin (shell history) integration.
It might be quite similar window/tab managing functionality, but for me it's the same thing that made me choose tmux over screen: it comes with a nice status bar as default and hotkeys are somehow easier to memorize.
The continuity benefit is much less than it used to be, now that we have systemd with `enable-linger` so we can make proper daemons.
that's not what tmux provides continuity for. the continuity is for interactive sessions. on my server i have more than 20 tmux windows, each one for one specific purpose. they have been running for several years.
1 reply →
because the OS window manager isn't superior. i have two dozen tmux windows in half a dozen sessions locally. i have shortcut keys to switch between sessions and between windows. i can do that while mixing the terminal with other gui apps. i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace.
> i have two dozen tmux windows in half a dozen sessions locally.
> i have yet to find a window manager that lets me group so many terminals into sessions all on the same workspace.
Locally-speaking, I don't really see the point of mixing tmux sessions and tmux windows. I wonder if you mean "sessions" -> tmux windows and "windows" -> tmux panes.
What about i3/sway? You can have a tabbed container (functions like tmux windows) with split containers inside (functions like tmux panes). You can even float the tabbed container with all windows organized inside.
I don't really see the point of mixing tmux sessions and tmux windows.
sessions let you group windows. i have a group/session for each project/purpose. one session is for all remote connections. one for my personal stuff, diary, etc. one for my hobby. one for personal dev projects, one for client work.
sessions also means that i can connect to tmux from multiple terminal windows. i generally have two windows, one for dev work and one for everything else.
generally i feel that having more than half a dozen windows in a session makes the session unwieldy, harder to navigate, because it becomes more difficult to find the window i am looking for.
which would be the same problem if each was a gui window. try to find your way around 20 gui windows.
4 replies →
I just logically group tabs into the same terminal window. All OS's have hotkeys for switching between tabs and windows.
sure that works, but then you are also using terminal functionality and not the window manager, which still shows the window manager as lacking in features, which was the argument i was responding to.
seriously, a window manager that can group windows and manage those groups would be awesome. workspaces help, but they are often just there, and can't be managed, reordered, named, etc..
actually, i think kde may have some of that functionality.
i still prefer tmux in any case because it is more scriptable, and it provides a detach function. although i recently started exploring wezterm, which can be configured to work like tmux and also has a way to detach and reattach sessions: https://news.ycombinator.com/item?id=44762241
I would typically not bother with tmux unless ssh is involved.