Live data from Hacker News

Make tmux pretty and usable (2024)

hamvocke.com

261–270 of 285 posts

Re: Make tmux pretty and usable (2024)

#261
I have used tmux, tmuxup, fzf and direnv to automate my workflow. It's pointed to the work folder, contains a project picker, invokes shell with defaults (npm run dev, python manage.py runserver etc), and fires up cursor - saving a lot of keystrokes for project initialization.

I have written about the process here: https://kashifaziz.me/blog/tmux-dev-workflow/

Re: Make tmux pretty and usable (2024)

#262

Earlier quoted context omitted.

I have a few embedded devices where flash space is limited. tmux is so much smaller than zellij, and it's not even close. Zellij is close to 50 megabytes, but tmux and all dependent libraries (minus libc, it's always there) is about 2 megabytes.

> Zellij is close to 50 megabytes, That's a Rust thing. It's what happens when you statically link because you monomorphise everything.

And the Rust practice of everything needing at least 300 libraries. It's slowly getting to JS levels of insanity.

Re: Make tmux pretty and usable (2024)

#263
post #244

Earlier quoted context omitted.

i have fedora. and yes, i am running make build. why did you choose wails btw? did you look at fyne? it's go-native and it seems to have a lot less dependencies. can the AI integration be turned off? i am not going to use it myself. is there a chatroom where we can talk through debugging my build problem? github issues? you didn't turn in the discussion forum for ttyphoon like you did for murex. or is there another p…

An earlier build used SDL directly. There were reasons I didn’t choose Fyne and that was basically that the effort wasn’t much less than working directly with SDL due to various (potentially self imposed) constraints. I then switched to Wails because I wanted to add Markdown, Jupyter support. And other things too. Quickly I realised it was too much for me to attempt SDL (even just the markdown parser proved an annoyi…

thanks for those details. your approach is very pragmatic and i appreciate that.

on AI, i am not concerned about a few menu items, but if we want to consider supply chain attacks as a risk, the less that gets downloaded and built, the better.

i'll open an issue then, i figure this is more for the benefit of other users of ttyphoon, and since this post is originally about tmux we are already off topic anyways.

Re: Make tmux pretty and usable (2024)

#264
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.

Typically upon control+c being mashed in a shell (unless the terminal is in raw mode or such) a SIGINT signal is sent to all members of the foreground process group, and most of the processes in that group (ideally, probably) go away. This usually includes a portion of the shell (which forked itself to spawn the pipeline or whatever, to call setpgid(2), etc) that usually ignores the signal. In this case it may seem like the OS is doing something, but really it's shell job control (assuming your shell has job control, which most now do, and that you haven't turned "monitor" off, which most folks do not). The kernel is mostly there for shuttling signals around and process bookkeeping.

However a different process management model is that each parent must in turn signal its child processes to exit, in which case if the parent dies before that can happen you easily get orphan processes. There are use cases for both the process group model and individual signal models, and pros and cons to each.

Re: Make tmux pretty and usable (2024)

#265
post #103
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…

That depends on how the children were spawned, no? prctl(PR_SET_PDEATHSIG, SIGTERM); or similar will fix this.

  $ man prctl
  man: No entry for prctl in the manual.
Maybe more linux will slop into POSIX and thence into OpenBSD in the fullness of time?

Re: Make tmux pretty and usable (2024)

#266
post #38

I would love to have a way to switch sessions easily, like with panes where I just click or have more shortcuts available

Here’s a simple session switcher: `bind C-a display-popup -E "tmux list-sessions -F '#{session_name}' | fzf --reverse | xargs tmux switch-client -t"`. No plugins, nothing fancy, just works.

Re: Make tmux pretty and usable (2024)

#267
post #224

Make tmux cut/paste work on mac terminal.app so I don't have to install iterm2 bloatware.

I select with mouse and paste to wherever, works every time? How can it not work? I think the only even loosely relevant setting on my .tmux.conf is: set -g mouse on

It's the non mouse stuff i want. It's a known problem with a lot of "try this" approaches to fixing but no categorical answer. Nothing wrong with mice but keyboards have a role too.

Re: Make tmux pretty and usable (2024)

#268
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.

https://github.com/zellij-org/zellij/releases/latest/downloa... '"> linux download Screaming into the void, I guess, but PSA. Don't use buttons for links. In my case, I couldn't right-click and copy the URL, but there are a lot of other reasons not to do this.

I've often wondered.. Why _do_ people do this? For one thing it's more code than the alternative

Re: Make tmux pretty and usable (2024)

#269
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 a few embedded devices where flash space is limited. tmux is so much smaller than zellij, and it's not even close. Zellij is close to 50 megabytes, but tmux and all dependent libraries (minus libc, it's always there) is about 2 megabytes.

and this is a great example why rust will never be relevant in embedded development that actually matters

Re: Make tmux pretty and usable (2024)

#270
post #128

What I don't see discussed is why tmux (and screen) are still a thing, when we have windowed desktops for 40+ years now. Disconnecting a session's lifetime from the connection's lifetime hardly need such lengthy tutorial. And displaying and arranging multiple virtual terminals was supposed to be the job of the terminal emulator and the windowing system.

windowed terminals and tabs don't keep their state without something like tmux. and they don't let me have multiple terminals on a remote machine.

only now we are seeing gui terminals to integrate such features: wezterm, ghostty, ttypoon, ... so we are discussing tmux because it took more than 40 years for those features to make it to the gui layer.

Post reply on HN