Hacker News Reader

Whereas I use it primarily for the persistence layer, since I'm often sshing on a flaky connection and it's nice to be able to leave things open and be able to come back to them, or to attach to a session I left open on my desktop when I'm away.

Tabbing/windowing is a nice bonus; I don't use tiling in tmux all that much, since as you said, it can be done on a different layer, but it is occasionally useful.

My biggest frustration is that there are like ten million places where you need to tweak options to have it behave like a normal shell (scrolling, selection, etc.). It would be nice if these were less quirky by default.

Recently I switched from Tmux to Kitty, and couple of days ago I realized that I really miss Tmux’s persistence. It’s just so easy to lose a session!

When GUI hangs or crashes (which happens with Kitty sometimes) I really want to be able to start it again and get the same session back. Especially considering that there’s no way to update configuration of running instance and that it loses its remote control socket if you launch another instance on the same socket by accident, hurdles like these can be profoundly inconvenient when you're in the middle of work.

That said, Kitty is really fast and decently scriptable (though perhaps not as flexible and definitely less straightforward than Tmux, primarily due to lack of consistency—some commands are remote-control only, others are internal-only), and with turned off window decorations it can look fantastic and offer all of the screen estate without the inconveniences of native macOS full-screen mode I had to use with Terminal.

Interesting because I'm using it mostly as a windowing/tiling use case. I liked it better than using multiple windows/frames in say Emacs, and I didn't like learning new window/pane splits using iTerm2 (OS X).

But you're super right, I have so many little "quirky" things that just don't work right, like I used to be able to easily double click a line and it would just copy it to a buffer; pasting from my host OS requires different key bindings, and my TMUX config file has slowly grown as I tried to get it working just right... Might be time for me to learn iTerm2 properly....(maybe I can modify keyboard shortcuts to be like Tmux for moving around to different panes....) But part of me worries about the time when I have to go back to a remote dev env where I'm expected to SSH to a protected source code machine.

I’m curious, can you share what industries this practice is common, sshing into a protected source code machine?

I worked in Security for a bit (that was actually a case of RDPing to a dev environment) and some friends at certain projects at big tech were telling me about their setups and how they had to learn Emacs again because all the code and their dev workstations were in a protected remote environment and no source code was allowed on their local machines.

In embedded, I did a _lot_ of development work _on_ the physical target hardware via SSH. It wasn't every product, but it was most. It wasn't from the beginning, but rather there was always some point in development time where the feedback loop would tighten up dramatically if the work was being done on a device on the bench.

Not the parent poster but for some financial services companies (bank, insurance), I have heard of development being done on a remote desktop, sometimes without direct ssh access.

http://www.brain-dump.org/projects/dvtm/ lets you have the windowing / tiling stuff without the session detaching.

some people combine https://wiki.archlinux.org/index.php/Dtach and dvtm in whatever combination they want to get screen/tmux without the giant codebases (I love screen, but I don't love that it still has code in it to connect to serial terminals)

Heh, connecting to serial terminals is the only reason I even have screen installed nowadays.

I wish there were a port of cu to Linux, but I haven't come across one yet.

> I mostly used it for windowing & tiling [...] it feels like they're battling to implement features at the wrong layer [...] In the end, I realized I just wanted a good terminal emulator

If you just wanted the windowing and tiling, wouldn't a tiling window manager be better? It's kind of weird that you concluded the right layer for window tiling was the terminal emulator.

Personally, I only use the window tiling features of tmux when I'm not already working inside a window manager (like when I'm on a /dev/tty*).

> If you just wanted the windowing and tiling, wouldn't a tiling window manager be better? It's kind of weird that you concluded the right layer for window tiling was the terminal emulator.

I tried a tiling window manager (not sure which) a long time ago and didn't like it, it felt too heavy-handed and unnatural to me. My daily driver is:

- GNOME Shell ...

- ... with the occasional Super+{Left/Right} for basic half-screen splits (e.g. term on the left and editor on the right)...

- ... and I use a little helper script ( https://github.com/ronjouch/marathon ) to run-or-focus apps.

With these three things, I meet my "simple tiling" needs and keep the flexibility I like from non-tiling WMs.

But Sway looks cool, I'll definitely try it one of these days :) , maybe I'll change my mind.

Maybe they didn't want tiling for the rest of the windows? Or maybe they use something other than Linux/BSD and can't run a diff window manager.

Holy hell, has the options changed between different versions of tmux. Getting a consistent version across multiple version is near impossible.

I used Fish for years and eventually switched back to Bash and then to Zsh because I couldn't really deal with all the differences in the two, and the lack of customization in Fish. I'm interested in giving it another shot, but I'd really like to know what you like about it in the first place.

I like Fish because I find it has sane defaults, i.e. {coloring, autosuggestions, completions} all work well out of the box with zero or little configuration.

You can replicate a fish-like feeling in zsh (coloring, completions, etc), but for that you need a plugin manager, a million bajillion finicky plugins, and then configuration/performance hell [1] happens. I tried that, got bored of it, then learned to fish and never looked back at zsh.

That being said, out of the interactive shell I don't like the exoticism of fish as a scripting language; I keep preferring shebanged, shellchecked [2], defensive [3] (ba)sh scripts, they're a stable and portable evil I know.

Also, I'm curious what makes you feel "lack of customization in Fish": what can you customize in Zsh that you cannot in Fish?

[1] https://github.com/zsh-users/zsh-autosuggestions/issues/29 , https://github.com/zsh-users/zsh-autosuggestions/issues/22 , https://github.com/robbyrussell/oh-my-zsh/issues/5569 , https://github.com/zsh-users/zsh-autosuggestions/issues/102 , https://github.com/robbyrussell/oh-my-zsh/issues/6338 . And yeah okay, most of these issues are about one specific plugin, and oh-my-zsh, which is known to be a terrible kitchen sink. Fair. But even then, I prefer fish's "batteries included" (and tested) approach to having to the alternative of doing all the mixing myself and dealing with weird plugins interactions :).

[2] https://github.com/koalaman/shellcheck

[3] https://jvns.ca/blog/2017/03/26/bash-quirks/