[godelski]

Yes, of course. What I'm trying to communicate is that if you're just doing things locally you can get all the benefits (sin sessions) from modern terminal emulators. Most people are using panes and tabs but switching to another terminal emulator will get you these and much more. If you're using the default terminal emulator, you should probably switch (you're installing a program anyways, right?).

That said, I still use tmux. Almost every day in fact. Because all my work is being done on a machine I'm not sitting in front of. This even includes at home. My main desktop is connected to a TV for videogames and movies. When I want to do work on it there's no difference if I'm sitting in front of my laptop or it other than it sitting in my livingroom keeps it cooler and gives it better air flow.

Edit:

Locally: my terminal emulator (ghostty) can do everything tmux can. I can do sessions (windows), panes, tabs, and all that. But with ghostty I also get images, a lower memory footprint (than stock emulator), lower CPU usage (than stock emulator), ligatures, and everything else. It is strictly better.

But I can't do {widows,panes,tabs} with remote connections. Hence, tmux. Which in that case, I will frequently give up capabilities (like images) for that.

[newlisp]

You don't mention the persistence of tmux sessions, which I find very useful for local development. Does ghostty have a client-server architecture too?

[godelski]

You mean like `window-save-state`[0]? (Windows and sessions are the same thing)

You don't need a server to handle this feature. Using a non-server solution even allows restoring after power cycles!

[0] https://ghostty.org/docs/config/reference#window-save-state

[newlisp]

I mean having long processes(batch jobs, backups, compiling, etc...) or even your opened terminal apps like your code editor or claude code don't get interrupted/killed if you accidentally close your terminal, or you terminal/desktop environment crashes/freezes. While essential for doing dev on remote servers IMO cause of "networks", is useful for local stuff too.

[godelski]

Tmux is going to solve some problems that your standard emulator won't solve. I agree.

  BUT 
  1) I'm unconvinced the things it solves that emulators don't do are common situations 
  2) tmux isn't "free". There are trade-offs that you have to make for tmux.

There's definitely edge cases where I do run tmux locally, but I find them rare and there's usually another solution (and I definitely do a lot more "weird things" than the average user will, so I run into more "edge cases").

But most users are turning to tmux for the {tabs,panes} feature (and then using sessions like anyone would use a window).

  > interrupted/killed if you accidentally close your terminal

Sure, I get you, but I'm also not sure what tmux is doing for you in most cases. I'll give you that it's easier to kill your terminal pane than it is to kill the tmux server, but it is still easy to kill a pane or tab in tmux. I think there's better defenses here to prevent those mistakes. I mean you can just put a window in a different workspace and get very similar defenses as to what tmux is giving you. You're right, that isn't a reliable defense, but that's true about tmux here too.

If you have a process running that needs to stay alive for long periods of time then does it need to be running interactively? It is pretty rare that long running processes need be running interactively. Not rare in the sense that an average user is going to do this infrequently, but rare in the sense of few users are going to do this infrequently.

  - You can always throw running jobs into the background by doing: <C-z> (suspend), `bg` (resumes program in background), and `detach` (so the process is not attached to the current terminal instance). 
  - If you're launching a job consider using `&` 
    - Remember, you can always reattach to a running process too. If you still have the terminal open it is trivial with `fg`. If you don't, then you can still attach with strace or gdb, but you'll probably need `sudo` and this isn't exactly trivial.
    - If you know your job needs to be interacted with then there's better ways to handle that communication like by setting up a pipe. But that requires forethought. 
  - or the best option is to actually run it as a service since you'll get a lot more benefits and flexibility through that. It's pretty quick to turn anything into a systemd job. 
    - You can interact with systemd jobs if you set them up that way. Lots of fancy options here from ttys, pipe, sockets, or containerizations. 
    - systemd-nspawn or systemd-vmspawn. Containers are honestly the best option for long running but interactive jobs.

   --- Aside ---
  Batch jobs: 
    script and should run in the background. Are your batched jobs not scripted? Just copy paste your loop into a file and add the header. I typically add a few more lines for logging and stuff but yeah. I mean if I want that output I usually want that output longer than my session will be alive, so logs. That way they also are organized.
  Backups: 
    unless you're doing a quick rsync then this really should be automated. A service is the solution. If you find yourself needing/wanting to manually run, you can also just call the systemd job. But yeah, if I have a one-time big sync, I'll pull up tmux (or caffeine). But that's different than always running in tmux.
  Compiling: 
    I'll be honest, locally I rarely have long compiles (or anything over a few minutes). Anything that is long and repeated should be incrementally compiled. I mean this is a much more robust strategy anyways and in a long compile there's a lot of potential disruptions that are far more likely than me closing my terminal window. But in those rare instances I usually throw the process into the background (or start with `&`) or will turn on caffeine or whatever to keep my machine awake. 
  --- /Aside ---

  > or you terminal/desktop environment crashes/freezes

This seems like a more complicated issue. Depends on the crash, right? But how often are you crashing? If frequently enough that you're going to default to running in tmux then I think you have bigger problems. Honestly, I don't think I can remember a time where only my DM or terminal crashed and the whole system didn't go down. Well... DM on a boot, but that's not the situation we're discussing. Maybe if I did something stupid like try to mess with the DM while the DM is running, but... I mean... tmux isn't going to fix the root problem... IDK if it will fix any problem there...

I'm not sure how often ghostty calls the window-save-state command but it looks like you should be able to call this frequently, though I haven't tried it and I'll give you this one because this definitely requires more work. Though ghostty will survive a reboot and you need a plugin for that with tmux. But either way, this is related to the lesson of backup often. Or commit frequently.

  > While essential for doing dev on remote servers IMO cause of "networks"

If we're talking about remote, well that's why I use tmux every day. I didn't say there's no point to tmux, just that the vast majority of things it does *locally* can be accomplished without it.

I'm 100% supportive of tmux with remote connections.

If you're having that spotty connection then I think the better solution is using something like mosh or the best option is configuring better timeouts in ssh{,d}_config. Look at `TCPKeepAlive`, `ServerAliveInterval`, ServerAliveCountMax` (s/Server/Client/g for sshd_config)

[arp242]

I cannot phantom why anyone would write lengthy walls of text trying to convince people "no askhually, your workflow is invalid and theres a better way!11" after they've told you very directly and clearly several times that this works well for them. People have different preferences. People are telling you that this works well for them. They don't really don't need to be condescendingly "educated". Learn to listen.