Nah, screen's main use case is as an ad-hoc method to daemonise random scripts.

Let's see, we have at least daemonize[0], nohup[1], and disown[2] for that. Some discussion of the differences: https://unix.stackexchange.com/questions/3886/difference-bet...

[0] https://github.com/bmc/daemonize

[1] https://linux.die.net/man/1/nohup

[2] https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash....

A more modern alternative is systemd-run: <https://www.freedesktop.org/software/systemd/man/latest/syst...>

Yeah this is 100% of when I reach for screen. “I’m not willing/ready to make this a service, screen detach here I come”

I switched to dtach for the first case.

dtach for session persistence. “Do one thing well.”

> Screens main use case is to open an emacs session remotely.

Not an emacs user, but for this, what does screen do that tmux can't?

Nothing at all. I’ve used emacs over tmux (and now zellij) for many years. Emacsserver can replace both of them, but that’s a different story.

Nothing but replacing it with something newer invalidates decades of muscle memory.

I switched to tmux eventually though.

I'm confused by this statement. Are you claiming this is the projects' stated goal? Their primary use in the wild?

It also has tramp mode which means you can use all your local packages remotely.

When I realized how powerful TRAMP was, I don't think I ever used screen/tmux again. I'm sure there are uses, mind. Just TRAMP fully hit all of my needs.

It really is magical, isn’t it? And although I rarely need to use it, I love the multihop setups where you can ssh to this system, then ssh again to this other, then mount an SMB filesystem using these credentials, and start editing.