Comment by bee_rider | Hacker News Reader

Comment by bee_rider | Hacker News Reader

Parent Full thread

The argument here seems to be: “the features you like about terminal multiplexers should be built into your terminal emulator, or your window manager, or I don’t see why they are really necessary.” Plus some complaints about influencers.

Sure, I’ll just replace my perfectly functional window manager so I can avoid using a terminal multiplexer.

Except I’ll still want a terminal multiplexer on servers, so I still need to be familiar with the way the tool works and I’ll still be happier if I have a nice config (sidenote: the article complains about needing very complicated configurations, but tmux is fine with like… 10 lines of configuration? You can solve the problem of over complicated configs by just not doing them).

Overall it kind of feels like hipsterism or engagement bait. Complaining about “content creators” is a very popular way to show off your bona fides nowadays. I guess this is just going back and forth on “no, you are the influencer/engagement fisher” but I think tons of people have been using terminal multiplexers for decades because they are boring and practical. If someone made a YouTube or a TikTok about them, I guess… I dunno, let the kids have nice things too, <shrug>.

> Except I’ll still want a terminal multiplexer on servers

Biggest reason not to use a terminal multiplexer locally, imo: There is nothing worse than hitting Ctrl-b twice for every action when you're also using the muxer remotely.

This tmux config turns F12 into a button to toggle the local leader key. You remote into tmux and hit F12, and now your leader key gets sent to the remote tmux instead of the local.

I don't use tmux locally anymore; but I still use the same leader key as tmux in wezterm, and I have a wezterm script to toggle it with F12 just like tmux.

Maybe you'll like it too?

  bind -T root F12  \
    set prefix None \;\
    set key-table off \;\
    set status-style "fg=$color_status_text,bg=$color_window_off_status_bg" \;\
    set window-status-current-style "fg=$color_dark,bold,bg=$color_window_off_status_current_bg" \;\
    if -F '#{pane_in_mode}' 'send-keys -X cancel' \;\
    refresh-client -S \;\

  bind -T off F12 \
    set -u prefix \;\
    set -u key-table \;\
    set -u status-style \;\
    set -u window-status-current-style \;\
    set -u window-status-current-format \;\
    refresh-client -S

I just have Ctrl-a set as the primary, and on remote boxes (where I run a tmux which ends up running inside a pane in my local tmux) I use Ctrl-b. Took about 20 minutes to get the muscle memory to adjust for it and now 15 years later I'm still very happy with it.

You can remap the prefix key...

I think the point of their comment is that if you're constantly connecting to different remote servers, you're not going to want to have to change the config on each server remotely. It's the same argument for understanding base vi as well and honestly does come in handy, but it's very discipline specific, most people don't have to worry about this use case.

In that case you’d probably want to change your local config away from the default.

But this is all very silly, I mean, of course there are workflows that aren’t assisted by terminal multiplexers. I’ve heard rumors of jobs out there that don’t even use computers. Adding one more job to the pile that doesn’t need the tool doesn’t say anything about the cases where it does come in handy.

I prefer it, to the point that I also use the same pattern for my WM with remote and virtual sessions. Keeping the same uniform shortcuts everywhere and just nesting a prefix is a lot easier that having to remember what shortcuts work in what environments. Moving and styling the tmux bar can help (or hurt) keeping muscle-memory mapped to the level you're operating on. At some point, any other approach gets too cognitively complex as you roam and scale[0].

If you only have nested use-cases rarely (or avoid them because you find them cumbersome) I can see how it never sticks but maybe just try leaning into it. YMMV, ofc.

[0]: Please prove me wrong, I'm open to try (:

Yeah, nested is a headache. The terminal use to connect to the server doesn’t have a tmux session running locally. That would be a nightmare.

I don't really buy the "I need multiple terminal sessions remotely" argument. It's just as easy to have multiple terminal emulator windows remoted into a server as it is to have multiple windows on a local session.

No it wouldn’t be just as easy.

Source: this is a description of my own workflow and preferences, so I’m the ultimate authority on the subject, haha.

> Source: this is a description of my own workflow and preferences, so I’m the ultimate authority on the subject, haha.

It's fine to choose your workflow by whatever criteria you decide, but on a post about workflows on a discussion forum, it's reasonable for mvdtnz to continue that discussion and not be laughed at for doing so.

I agree that tmux or screen is a must-have tool for servers.

But you certainly didn't read it all, or at least to the point where he goes more in depth of how crazy the working with Zellij is. After reading the parts of the interview with its author I'm not even going to check its webpage or trying it.

tmux for the worth. Boring, old technology = stable, well defined, well tested, without cognitive overload. Because life in IT is already hard enough.

Zellij does sound pretty bad.

Reply on news.ycombinator.com