Live data from Hacker News

Getting Started with Tmux

ittavern.com

81–90 of 160 posts

Re: Getting Started with Tmux

#81

Tmux becomes more awesome when you use something like Alacritty or Kitty [EDIT: scratch Kitty, this mainly applies to Alacritty] and map your system's key (Apple's command key or... whatever it would be on Linux or Windows) and use that as your "tmux key". That way you can make single-chord bindings for all things tmux and life becomes better. If you use Vim, adding VimTmuxNavigator[0] improves things so much. For ex…

For what it's worth, you can just do this using Alt (i.e. 'meta'). No special terminal required. Just use `bind -n M-` to say 'no prefix' and use meta-.

For example, `bind -n M-1 select-window -t 1` means Alt-1 goes to Window 1 for me.

I use Alt-h, Alt-j, Alt-k, Alt-l for vim-aware pane switching (with some vim config too), e.g. via `bind -n 'M-h' if-shell "$is_vim" 'send-keys M-h' 'select-pane -L'`. I have a load of Alt- mappings.

I use iTerm and Windows Terminal primarily, but it works on everything, really. Though sometimes you need to adjust what 'alt' means; in iTerm, you need to make Alt be Esc+ (I think).

Re: Getting Started with Tmux

#82

Earlier quoted context omitted.

Interestingly enough, one of the stated goals of kitty is to make the usage of tmux unnecessary. Considering your comment (and many others like it), I don't think that has quite worked out. Still, kitty is one of my favorite terminal emulators and I'd urge anyone who hasn't tried it to give it a shot.

Reading more about Kitty now is peaking my interest. I feel like there is a reason I ignored Kitty in the past but I can't remember.

For me it was the excessively minimal defaults. I also forget the exact issues, but I remember Alacrity felt usable even before editing the conf file; Kitty didn't.

Re: Getting Started with Tmux

#84
post #14
post #5

I've only used tmux for about One of my favorite scripts to run is a tmux script that creates a new session with about 7 windows of running my company's project (one window for notes, 3 windows for the backend (runner, code, tests), and 3 windows for the client (runner, code, tests). It's even tweaked further to open up the code in vim, and when used in conjunction with something like harpoon.nvim I have access to my…

Did you check out tmuxinator? Sounds like you reinvented it, cool, but maybe there’s some inspiration to be had.

Not the OP, but I did riff off of tmuxinator recently. tmuxed talks to tmux directly out-of-band to avoid running over user input and supports things like "wait before sending more input" for cases where `sleep` isn't desirable. I envisioned it being an orchestrator layer over tmux rather than a "new thing" to learn; while it's largely finished for my normal use cases I've been thinking about how sometimes it'd be awfully useful to be able to orchestrate tmux commands and not just send-keys.

Single binary, too, so no Ruby dependency. I really should get it into Homebrew one of these days...

https://github.com/eropple/tmuxed

Re: Getting Started with Tmux

#85

The best way to use tmux is with -CC, which iTerm maps to native UI. tmux tabs and panes become native tabs and panes and your session is immortal, and it’s a far better experience than mosh or whatever the latest thing in this area is. I have never bothered to figure out how the keybindings actually work and I probably never will, but I enjoy using it all the time because of this.

Agreed 100%. This is iTerm2's killer feature IMO, and it's the only thing that keeps me on a Mac for my work laptop.

Re: Getting Started with Tmux

#86
These days I mostly stopped using tmux over ssh. If one can install software on a remote system, then I just run a VNC server and use a GUI editor or IDE to edit things. The big plus of this is that copy-paste just works and I can use various shortcuts that are problematic inside a terminal emulator. And if one can use xpra, then running a GUI terminal remotely over a fat but high-latency link can be faster than using tmux on a remote system. The terminal protocol was originally designed for slow but low latency links and is not good at latency hiding.

And if I cannot install, then it is likely that tmux is not available either. So I use lsyncd to edit locally and transfer the edits to the remote system. For running commands I just run ssh host command then.

Re: Getting Started with Tmux

#87

As a heavy GNU Screen user for the last 2 decades it’s always in the back of my mind if I should be switching to tmux. Maybe there is a compatibility mode. For those who switched from screen what was the biggest benefit?

I used screen for about a decade before switching to tmux. The biggest immediate benefit was that terminal configuration across systems was much less brittle. My backspace key backspaced, color consistently worked, etc. Over the past 10+ years of tmux use I've become increasingly more sophisticated in my usage (in particular 1) nested tmux sessions, 2) heavy use of the kakoune text editor's tmux integration), yet my .tmux.conf file has all of 15 lines of content. One other thing: tmux has yet to crash on me, but screen certainly did so numerous times.

Re: Getting Started with Tmux

#90
post #86

These days I mostly stopped using tmux over ssh. If one can install software on a remote system, then I just run a VNC server and use a GUI editor or IDE to edit things. The big plus of this is that copy-paste just works and I can use various shortcuts that are problematic inside a terminal emulator. And if one can use xpra, then running a GUI terminal remotely over a fat but high-latency link can be faster than usin…

> For running commands I just run ssh host command then

That's fine, right up until the point you're running a command (or a series of commands) that change things on the machine and your connection gets broken. When that happens there's a very good chance the command being executed will fail in some fashion. If you're very lucky it won't be a big deal, but depending on what you're doing it could be dangerous.

I would strongly advocate for using either screen or tmux as a matter of course on any remote server when you're executing commands on it. You don't need to do anything more with them other than just have a single window in it. You just don't want the command execution to be specifically tied to your SSH session.

At the very least, screen or tmux enables you to get right back to what you were doing with no loss of output, and at the most it enables whatever commands you were executing to finish executing without risk of broken pipes killing them mid-flow or whatever else might end up being catastrophic.

Post reply on HN