undefined | Better HN

0 pointseviks4mo ago0 comments

1. if you use some external window manager tool, what workflow does tmux/term provide you that OS-level windows with that tool do not?

2. specifically for "keyboard-centric tech users" that's a big fail since the terminal platform is not capable of supporting advanced keybindings presisely because all they do is "target the lowest common denominator" (as defined in 1965) of keybinding support!!! So your cool setup from a GUI code editor is simply not transferrable.

3. this is very rare, I mean, just look at the screenshots, a lot of them couldn't even add non-gapped borders=== ---!

0 comments

OkayPhysicist4mo ago

1. I think the fact that you refer to "some external window manager tool", whereas you know the name tmux off the top of your head illustrates that first point.

2. Again, it's not about the possible capabilities. Objectively, GUI programs contain a superset of possible TUI programs (since your GUI program could be a terminal emulator). It's about it being a shibboleth: I can be pretty confident that the TUI application will have a keyboard-based workflow, and I can be pretty confident that the TUI application will be targeting a technical user base, because those are the only people building and using TUI tools. The "lowest common denominator" in that sentence was referring to the users not the systems.

eviksOP4mo ago

1. I think the fact that you have nothing of substance and have to read into the fact that after reading your comment explicitly mentioning tmux I repeated that illustrates the point is invalid.

2. but what's the value of a shibboleth if it's not reflected in capabilities??? Why would you care that a TUI app targets "tech user base" if you also know it will be less capable in your 'keyboard-centric' workflow due to platform limitations? And LCD for users just doesn't make sense, what user quality are you min-aggregating?

1 more reply

j / k navigate · click thread line to collapse