Hacker News Reader

Comment by superfish | Hacker News Reader

I super duper highly recommend iterm2 (macos) + its integrated tmux support. It was relatively popular in my circles at google when I was there.

It comes with this tool’s benefit of native scrolling/cp paste PLUS the huge benefit of “right click to split vertical/horizontal”.

View on HN

Don't overlook the awesome "automatically bury session" option, which hides the "actual" iTerm2 window running the tmux control plane: https://iterm2.com/documentation-buried-sessions.html and this is the preference I mean: https://github.com/gnachman/iTerm2/blob/v3.5.2/Interfaces/Pr...

I also have dedicated .ssh/config entries for ensuring that ssh connects directly to tmux:

  Host whatever-mux
    Hostname whatever
    RequestTTY yes
    RemoteCommand /usr/bin/tmux -u -CC att

The `tmux -CC` is pretty dope. I’m still surprised that not more terminals have picked it up yet.

Most GUI features (new tab, new split, scroll, search, copy/paste, etc.) just work, and it all syncs with `tmux`.

Be aware though that it can be a bit buggy if you have a fancy `tmux.conf`, and that if you rely on any `tmux` plugins then most of those simply won’t work.

I'm especially surprised that tmux itself can't be used as a client of a remote control mode session.

It is pretty annoying that the only terminal that I know of that supports tmux control mode only works on mac.

I looked into this at one point. IIRC it turns out control mode was only added to tmux by the iterm2 dev, for use in his own project. So I guess he didn't care about adding support to tmux itself.

What benefit would you get if tmux itself became a control mode client?

You'd get pretty much same experience, with textual splits, modeful keyboard shortcuts to access scrollback & copy/paste etc. — which I'm not saying is bad but tmux already does that. Well, I suppose over ssh it'd allow you to access remote tmux session(s) from a local tmux, so maybe allowing little more flexibility mixing panes from multiple remote hosts(?) But still pretty much similar.

The whole point of control protocol was to allow native [G]UI where each pane feels like a native standalone terminal, no?

For use over ssh. It would, ideally, give me:

1. Ability to use local tmux configuration for tmux sessions over ssh. So I don't have to worry about using the default bindings when connecting to a host that doesn't have my tmux config, mouse support is already enabled, etc.

2. Ability to combine and organize remote panes alongside local panes, or panes from other remotes

3. Avoid ending up with nested tmux, where I have a remote tmux session inside of a pane of a local tmux session, which is a pretty terrible experience.

I'd also love it if linux terminals supported it too, but that doesn't seem terribly likely to happen anytime soon.

On that front: I've been using wezterm which includes a built-in tmux+mosh functionality, and it works quite well. It gives you first-class scroll/copy/paste management and multi-windows, plus session re-attachment. Probably 50% of my use of my mac is just SSHing in to my Linux box, and wezterm works great for that.

Last I tried there’s 2 major limitations, one is that the version on both ends has to be compatible, another is that it seems the wezterm at the host must be available in the system default PATH. This makes it hard to adapt to arbitrary remote systems that you have limited control of. Tmux+mosh doesn’t have these limitations (well I’m sure the mosh client and server must be compatible to each other but given it is so stable that the last 2 updates are 5 years apart there won’t practically be any problems).

Yes, the versions between client and server do need to be in lock-step. As far as needing to be in the system default path, I haven't run into that: when I initially started using it, I had dropped the executable into ~/bin and that seemed to work (that is in my shell path).

It depends how the rc files are initialized though. I remember last I check I couldn’t get it work on one system (that I don’t have control over those in /etc and those set in my home is not initialized at that stage.)

Mosh implemented a flag to include in the client side: —server=… which solves this problem.

The last time I used it, which was probably pushing 5 years ago, it was a big drain on the battery. It was enough that I went back to Terminal.app. Anyone else experience that? Has it improved?

I believe iTerm2 has been GPU accelerated for some years now which probably helps. I’ve only been using it for 3-4 years and haven’t had this issue.

can I still use my keyboard shortcuts for switching between sessions and windows within the session?

I am much happier with that muscle memory than whatever the iterm shortcuts would be.

Reply on news.ycombinator.com