How to avoid running tmux in VSCode-terminal | Hacker News Reader

How to avoid running tmux in VSCode-terminal

rakim.bearblog.dev

2 pointscuanim5 comments

> If you're like me and have a default attach-session setup in your ~/.zshrc

Serious question, as a user of tmux - why would you want your new terminal windows to automatically connect to tmux every time?

Doing the same (though new-session rather than attach) - tmux is just part of my everyday workflow. I use multiple tabs/panes/buffers/windows /splits/whathaveyou constantly where I guess you may be relying on your terminal emulator or window manager for the same features?

To me this reads like "As a user of X11, why would you want your session to start a desktop environment on login?"

Because the first and only thing I'd do unless something is broken is run [startx/tmux] anyway.

No, I definitely use tmux for that stuff instead of whatever my terminal app has built-in - but usually I only have a single iTerm2 terminal open for my local tmux session, and any new windows or tabs are either meant for remoting into other servers, or are quickie one-offs that I explicitly don't want to connect to my "main" tmux session.

So when I hit CMD-T or CMD-N on my local machine, I don't _want_ to be connected to my tmux session, since I'd just have to hit `D every time to disconnect, and then run "ssh elsewhere" and connect to tmux there.

I think where you're getting confused is that you're replicating local functionality that iTerm2 offers (cmd-D for a new terminal session) versus tmux features that are important and useful when used on a remote host.

Using tmux on a remote host means that you can always detach and re-attach to the remote host session when you want to. You can do that on your local host too, but this is only useful, ultimately, if you have long-running process that you want to leave running - and be able to re-attach to - while also being able to quite iTerm2 completely ..

Consistency and permanence. There is much utility to be gained in having a terminal that you can always re-connect to, from different networks and indeed different client computer terminals, and yet still maintain your remote state on the system running tmux.

For example, I regularly run jobs that can go on for hours and hours, without much predictability - so using tmux means I can start the job at work, but then check in on it later on my iPhone during the commute back home, and then from my home-office system later, without fuss.

Using tmux this way makes your remote host a reliable development partner instead of giving you hassles if you lose your connection/need to relocate to another network provider/use a different terminal client than the one you started at the office, etc.

Reply on news.ycombinator.com