I think the biggest problem I encounter when trying something else than tmux is copy-pasting without having to use the mouse. How does the "local terminal guis" you suggest as alternatives handle that?
Not quite. I don't think my setup is very special, so, I describe it in more detail:
My company provides me with the laptop, VPN connection to the office network, which, in turn, connects to our (tiny) datacenter, where actual work happens (i.e. compilation, CI, testing, all happen there).
Sometimes I work from the office, other times from home.
The datacenter has several "jump" servers having distinct roles, there is a server that lets you connect to our OpenStack cluster, another has some resources to run a bunch of unrelated VMs in KVM, yet another one is the storage for all kinds of artifacts, s.a. Linux packages, Linux distro images, Docker images for development and testing, and then there's CI cluster.
So, my typical setup is like this: I have an ansi-term buffer per jump server. The jump servers are running my tmux session. So, every time I have to move my laptop to a different network (eg. going home from office), I reconnect to the jump servers and to the tmux session they were running so that I can pick up from where I left off before disconnecting from office VPN.
If TRAMP could have a persistent session, maybe, I'd not use tmux (I don't like that I have different commands for managing buffer appearance and clipboard). On the other hand, tmux is more universally used (at least in my company), so that sometimes I can simply ask a colleague to connect to my session, if they need to investigate some strange situation (only a handful of people are using Emacs, but almost everyone would be able to use tmux at where I work).
Might be worth looking into detached.el for persistent sessions? Tbh I haven’t set it up properly myself, but I did watch the talk from EmacsConf and I plan to look into it further.
Thanks for this! Unlike a stereotypical Emacs user, I haven't touched my configuration in a few years. Guess, I'll need to do some cleanup / research in the near future.
I switched from screen to tmux because it was often impossible to detach a remotely attached screen (for example when your ssh connection dropped and you wanted to reattach to screen).
Would `screen -d -R` & al not work? From `man screen`:
-d|-D [pid.tty.host]
does not start screen, but detaches the elsewhere running screen session. It has the same effect as typing "C-a d" from screen's controlling terminal. -D is the equivalent to the power
detach key. If no session can be detached, this option is ignored. In combination with the -r/-R option more powerful effects can be achieved:
-d -r Reattach a session and if necessary detach it first.
-d -R Reattach a session and if necessary detach or even create it first.
-d -RR Reattach a session and if necessary detach or create it. Use the first session if more than one session is available.
-D -r Reattach a session. If necessary detach and logout remotely first.
-D -R Attach here and now. In detail this means: If a session is running, then reattach. If necessary detach and logout remotely first. If it was not running create it and notify the user.
This is the author's favorite.
-D -RR Attach here and now. Whatever that means, just do it.
Note: It is always a good idea to check the status of your sessions by means of "screen -list".
Believe me I tried all combinations, lowercase and uppercase, it would just freeze, as if it was trying to get my session back, but it wouldn't do anything. It happened often, and I would lose my sessions, so I learnt to use tmux, and that's what I've been using for ten years.
Yeah... I kind of vaguely remember having an issue with this sort of thing 20 years ago, but I don't remember if I even knew about force detach at the time. I definitely haven't experienced a screen session I couldn't detach--and I use screen a LOT--in at least 10 years... probably 15.
