Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make tmux pretty and usable (2024)

hamvocke.com

Post reply on HN
Print view View original

251–260 of 285 posts

Re: Make tmux pretty and usable (2024)

#251

Post by hrimfaxi »

ori_b wrote: post #142
ndr wrote: 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.

Once I discovered window managers and graphics, I stopped using half-baked features to emulate them in the terminal. I use tmux to reattach to programs after the network connection dies, and not really anything else. I would welcome a version of it that stripped out everything but that, and just replayed the last few pages of scrollback on reattach.

Using mosh would help specifically with the network reconnection piece.

Re: Make tmux pretty and usable (2024)

#252

Post by mrexcess »

Rebinding C-b to C-a is a necessity for those of us whose muscle memory formed on GNU screen, been doing this for years. I like to set status-right to include host load average, with something akin to:

set -g status-right '#[fg=colour39, bg=colour234]#[fg=colour160] #h #[fg=colour088]avg: #(cat /proc/loadavg|cut -d" " -f1-3) '

Re: Make tmux pretty and usable (2024)

#253

Post by welcome_dragon »

heatmiser wrote: post #11

I read "tmux 2: mouse-free productivity" in a weekend years ago and it may be, pound-for-pound, one of the more impactful books on my productivity. Seems like they are keeping up-to-date too: https://bookshop.org/p/books/tmux-3-productive-mouse-free-de...

This book is fantastic!

But ... Why not link to the Pragmatic Programmer page for it? https://pragprog.com/titles/bhtmux3/tmux-3-productive-mouse-...

Re: Make tmux pretty and usable (2024)

#254

Post by MisterTea »

alecsm wrote: 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.

Total opposite. I adapt to the defaults meaning I almost never customize anything. Tmux? Game controls? UI look? Default. I am almost never met with surprise unless I am sitting in front of someones OCD config.

Re: Make tmux pretty and usable (2024)

#256

Post by Witty0Gore »

I run tmux inside Termux on my phone to manage a couple of long-running Node projects. It's one of those setups that sounds cursed until you realize it just works. Session persistence is the killer feature when your terminal lives on a device that might close the app at any time.

Re: Make tmux pretty and usable (2024)

#257

Post by bigbugbag »

ndr wrote: 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 clicked and instantly gave up on Zellij due to the horrible design fails on the first page supposed to introduce the software to the user.

upfront breaking the basic expectation of having a clickable link is enough for me to know that this piece of software is badly designed and is not worth my time.

Re: Make tmux pretty and usable (2024)

#258

Post by Havoc »

The tricky part for me is getting it to behave with other fancy TUI stuff. eg both tmux and neovim stuff want to use the bottom row in terminal and neither seem to have the intelligence built in to compensate

Re: Make tmux pretty and usable (2024)

#259

Post by 2oMg3YWV26eKIs »

johnfn wrote: 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…

Very cool. Opening the tmux session in a new tab rather than a new window was an improvement that I wanted when I tried this. Here's how to do it: https://stackoverflow.com/a/54756013/22828008

Re: Make tmux pretty and usable (2024)

#260

Post by hnlmorg »

em-bee wrote: post #244
hnlmorg wrote: post #225

Earlier quoted context omitted.

> unfortunately the build now fails with "frontend.go:39:12: pattern all:frontend/dist: no matching files found" How are you trying to build it? Are you calling make? Also what OS are you on? make build > i am also a bit taken aback by the many dependencies. with heightened risk of supplychain attacks and dependency failures that feels a bit scary. Yeah, I agree with you there. Most of my projects are very conservati…

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 annoying time sink) on my own. I think the terminal itself is worse for change so there might be a point when I revisit this switch and change my mind again.

There was a brief period when both Wails and SDL were supported front ends. The idea being you could chose one based on a Go compiler tag. But that proved hard to maintain.

There was also a time when the terminal was SDL and Wails just did the markdown stuff. They were different applications that passed messages via a rudimentary IPC. But that resulted in a multi-window hacky mess.

So the current design is the compromise I’ve settled on but will likely change my mind at some point again.

As for the AI, there isn’t any compiler flags to disable it. But it doesn’t work without you supplying an API key anyway. And the integration is just a few menu items so, hopefully, not intrusive. Which would also make it pretty easy to hide those options behind a compiler flag.

I’m happy to chat as a GitHub issue if you’d prefer. I don’t hang out in may other places these days (time constraints)

Post reply on HN