I do see the point of reattaching to shell sessions or attaching from multiple devices.
But I already have a window manager that can manage multiple windows. I can reattach to as many sessions as I like and use my window manager to move them around. I don't see why I would want another window manager inside of an application. These nested window managers just seem to add complexity.
2) If i'm shelled into a system I just want to open another pane quickly to look at something, not open a new window, ssh, then move to that directory.
3) I get tired of configuring things to work the way I like. If I can copy my vim and tmux config, I know I can get to work and be comfortable. I don't have to worry about making different different OSs and terminal emulators act the same. I want my coding workflow/muscle memory to be based around things running in the terminal, not a mix of terminal and non-terminal/local things. It seems more unix philosophy oriented to me.
4) I can move from office to lab or go home and pick up right where I left off without any remote desktop nonsense.
It’s really not that big if a stretch to see how they would be useful or even necessary when accessing servers (or any machine) remotely. You can have multiple shells and multiple things running, without having to re-login for each separate thing. And for critical processes you need to run, you want some protection to stop them getting killed if there’s a network problem.
As for multiple shells I just use SSH multiplexing and keep my tmux sessions having one window each. Then I can regroup or reorganize however I wish and still use the same window manager. But I use an SSH key anyways so logging in again is transparent. (The multiplexing just speeds it up a tad)
> And for critical processes you need to run...
I explicitly said that I understand the benefit of reattaching. I just personally don't find a use case for the multiplexing part.
If you meant “I personally don’t use this feature but I can see how others would find it useful”, then that is not what is meant by that phrase.
I use customized keys for navigating easily around many tmux windows where I like the low overhead so it doesn't break my train of thought).
And with tmux panes: it's great occasionally to be able to send the same keystrokes simultaneously to all panes, like to multiple remote hosts). Something like a similar konsole feature, or a variant of pdsh+dshbak.
That and fvwm (also customized) make it so I can get where I want between tasks or apps with the fewest keystrokes I've found so far.
Edit: that plus that tmux allows scripting, such as to set things up for me automatically after rebooting, in ways that I'm not sure how I would do with shell scripts -- it has added another sphere of automation that I didn't have before -- maybe similar to what one could get with the expect language -- like simple automation inside both shells and apps running in them. Plus more features it has that I haven't tried yet. It is really rich.
Another possible benefit from tmux is that it is originally developed as part of, and included in OpenBSD's base distribution, so it hopefully gets the kind of attention and high standards for quality and security as the rest of that OS (like OpenSSH in that regard). (This is not to criticize the other products in this space -- they may be excellent also.)
I think the reasoning is that the client terminal could change, so the multiplexer ‘must’ emulate a terminal. However, my client terminal type in fact does not ever change, and I would prefer to have it available rather than the multiplexer's half-baked emulation.
I as quite happy & pleased when Google's Chrome on Android had tabs each appear as tabs in the OS. I have too many tabs, but I enjoyed that it was up to my launcher, up to my os to help me work with that. It gave me flexibility & options to approach the problem. Where-as, when Chrome went back to managing tabs itself, it's both been a disaster for me (new tab window shows me the start of my tabs, which has some years old tabs i only need occasionally), and a sadness, a defeat, that the OS can no longer manage this thing.
> I do see the point of reattaching to shell sessions or attaching from multiple devices.
I've recommended dtach[4] elsewhere[5] in this topic & here-by recommend it again! Very lightweight detachable proxy for persistent programs. I run vim inside of it, so I can attach/detach. Vim has terminals inside of it, so that's all I needed.
[1] https://omar.website/tabfs/
[2] https://news.ycombinator.com/item?id=25600338
[3] https://anildash.com/2021/01/03/keeping-tabs-on-your-abstrac...
The Chrome is an interesting example because it seems that some people liked it but it was arguably a bit of a botched implementation. (It seems like when Chome was killed and opened again it would put all of the tabs at the front, instead of sorting them by the time each tab was last used). Also people were complaining about no longer being able to swipe between tabs, but with Android gesture navigation this shouldn't be an issue anymore.
I'll take a look at dtach too. I think one of the benefits of using tmux just for reattaching is that tmux is widely used and tested against all sort of shell escape codes. I have a slight worry that the less popular tools will not handle all of the cases as gracefully. I'm hoping that I am wrong though and it works well.
Yeah, I've always thought it was weird that the X11 window management protocol wasn't extended to accommodate native tabs, so it's always handled in-client.
> I've recommended dtach
dtach is great! I've always wondered why people were so enamored with screen and tmux, when I don't really want a second, full-fledged terminal emulator running inside my desktop terminal emulator—I just want to detach from sessions. Most importantly, though, I want this to be baked in, ideally at the system level, but would settle for dtach-like integration with gnome-terminal; whatever allows this to be done lazily, without needing the foresight to use dtach from the beginning—just like you're not required to specify ahead of time whether you want to use job control (Ctrl-Z) at the time that you start the process.
It's a big shame. Two examples of natural growth with high utility that have just never happened, because we're supposed to stay stuck at the state things were in in the early 90s or something.
In the first window, I have IRC, in the second a Twitter client, and in the following whatever random stuff I'm hacking on at the moment.
This means I can keep online from wherever I have an ssh session. Very convenient!
I do see the point of them on remote machines