Live data from Hacker News

Make tmux pretty and usable (2024)

hamvocke.com

181–190 of 285 posts

Re: Make tmux pretty and usable (2024)

#181

I'm constantly fighting with tmux copying. I want it to perform like native copying, but in mouse mode it seems to copy more characters than I want, copy newlines when I don't want them, and doesn't copy to clipboard in tmux-in-tmux situations.

You can use vi copy mode. It makes selection a lot easier.

Re: Make tmux pretty and usable (2024)

#182
post #12

I like having a red bar for tmux running as root and a blue one for running it as a normal user, e.g. for root: set -g status-style "bg=red" I also like to have the bar on top and the status centered: set -g status-justify absolute-centre set -g status-position top

Do you use this when running tmux remotely?

(I only run it in my own machines so it never runs as root anyway)

Re: Make tmux pretty and usable (2024)

#183
post #17

I had my tmux customized to the point I forgot how to use it on a clean install which is a problem when I'm sshing into a server. I wish it had better defaults but now I run it as is. After a while you get used to it. The only thing I always have to change is the mouse scroll and my brain cannot retain the exact command.

I think of this as the curse of Emacs. Infinitely configurable, thereafter entirely unique in the universe, which can be a double edged sword. See too (maybe it's the same thing) The Lisp Curse.[0]

[0] https://news.ycombinator.com/item?id=2450973

Re: Make tmux pretty and usable (2024)

#184

Ctrl-a interferes with readline shortcuts. I've been using Ctrl- : nothing, as far as I know, binds to that. unbind C-b set-option -g prefix C-Space bind-key C-Space send-prefix

I very recently learned that with most readline apps and terminal password inputs, ctrl+u clears the input.

Very handy when you make a typo far into a long password and can't keep track of whether you've mashed backspace enough.

Re: Make tmux pretty and usable (2024)

#185
post #77

Guys, did you know about tmux control mode? It tells the host terminal to treat tmux tabs as actual tabs in the terminal. That means that things like scrollback, tab navigation, copy paste, keyboard shortcuts, etc are all handled natively, and you can visually see all your tmux tabs! It doesn't have great support across all terminals, but it does work great in iTerm 2. Try `tmux -CC` in iTerm. For a tmux novice like…

Was about the mention this, -CC has been working perfectly for me

Re: Make tmux pretty and usable (2024)

#186
post #3

I gave up on it once I discovered https://zellij.dev/ Just even for how tab and panes are setup, and how it's good for scrolling and text selection with your mouse for copy pasting.

I have been using zmx for the last 2 weeks. It's still a bit buggy (screen repainting) but quite pleasant to use with ghostty. https://github.com/neurosnap/zmx

Thanks for the report, I heard about it recently and was wondering how buggy it was since it's very new. I'll probably still try it soon.

Re: Make tmux pretty and usable (2024)

#187
post #3

I gave up on it once I discovered https://zellij.dev/ Just even for how tab and panes are setup, and how it's good for scrolling and text selection with your mouse for copy pasting.

I tried zellij and it feels like its ui was designed by someone raised in the world of blade runner 2049

Re: Make tmux pretty and usable (2024)

#189
post #82

Earlier quoted context omitted.

A `kill -9` will cause many a process to die and give no chance to cleanup any child processes. Some percentage of users continue to use `kill -9` by default, which may result in a mess of a process tree. Otherwise if the crash is bad enough that cleanup code cannot run (maybe it's being run on OpenBSD and an incompetent programmer didn't check the return value of a malloc and for some reason the kernel now nukes the…

TIL. I didn’t know it’s the responsibility of the parent, thought OS automatically handles child processes.

When a child process finishes (that is not actively being waited on) it is left in a "defunct" or "zombie" state and will stick around in the process table until the parent process waits on them to fetch exit code. When you kill a parent process with active children, these subprocesses will become orphaned and re-parented to the OS pid 1 (or another "sub-reaper" process depending on your setup).

The OS will typically not kill orphaned/re-parented processes for you. It will simply wait/reap them so they are not left as zombies once they complete. If your parent process spawns something like a daemon server that needs an explicit signal to be stopped (e.g. SIGINT/SIGTERM), these processes will continue to run in the background until they are manually killed or they crash.

Post reply on HN