Other benefits:

1. Consistent font and sizing. Pick the font you find easiest to read and set it in the terminal, now all TUI apps use it at the correct size.

2. Consistent theming. TUI apps use the same color scheme as your terminal, as your vim, etc. A consistent "desktop" is less distracting. Especially when you don't have to deal with crappy Electron apps displaying animations and ads (looking at you Discord).

3. Efficient on screen real-estate. Most TUI apps don't waste a lot of space on "padding", "giving elements space to breathe" or other "correct UX patterns". They tile nicely.

4. Never and issues copy and pasting. I used a GUI chat app recently that wouldn't let me select text, seriously.

5. Did I mention they are fun to use and relatively easy to develop?

And built in remote use via SSH.

Yeah they all use the same palette, but they don't all use the palette the same way.

And copy / paste, "hm does this TUI intercept mouse clicks, ah it does, oh what was the key combo for my terminal emulator that allows to skip that? Crap I pressed ctrl-c instead of ctrl-shift-c". Or worse when you want to select text in a column-based TUI and your terminal emulator doesn't have any sort of column-selection handling.

Well-designed GUIs can be fully keyboard operated, where the mouse-driven interface only serves as a way to educate the user about which functionality is available. I'll use Tera Term (a serial terminal emulator) as an example. If you want to start a serial XMODEM transfer, you can figure out how to do it just by clicking around the user interface. You click on "File", then "Transfer", then "XMODEM", then "Send". Once you do it a few times, you remember the layout of the menus, and can start navigating solely by keyboard. Instead of "breaking your flow" by having to reach for the mouse, you just hold down Alt and type "FTXS". This is much faster, and you learned how to do it entirely from just using the program and observing which letters are underlined in the menus. There's no need to look at a manual or help page.

A well-designed TUI and GUI have great keyboard nav, discoverability, UX, and all. The question is more about what you want for the 99% of UIs that aren't well-designed nor polished, and what kind of worst-case you want to deal with.

By default, TUIs have bad discoverability unless the developer puts in the effort. But at least you have keyboard navigation and run in a terminal.

By default, GUIs have bad keybindings unless the developer puts in the effort. In the worst case they aren't even kb navigable. But at least they tend to be discoverable.

they do not, GUI is more capable of handling keyboards than TUI because terminals still have pretty dumb limitations where some modifiers aren't even visible/bindable!

This seems trivially false or disconnected from the important part of what I'm referring to here.

TUIs have to be navigable by keyboard. They could be garbage in every other way, but at least they have that.

GUIs might have keybindings as polish if the developers put in the effort. Otherwise they either don't have keybindings, or they rely on generalized keybindings that come with the OS/UI toolkit that can be bad/impossible in arbitrary ways, like if tab is swallowed by an input so you can't even tab past a component or dismiss a modal. Or the only GUI is inside a web browser.

This seems trivially false to you because you don't rise above the trivial, but also forget about similar trivial fails in TUIs.

> They could be garbage in every other way, but at least they have that

Not really, they could also not implement keyboard input for some interactions and only react to mouse. You could have a click-to-open-url in your terminal without a keyboard fallback setup. Of course, you could set it up, but that would be "polish if you put in the effort" There is no limit to garbage.

> Also once your workflow is increasingly keyboard based (like when using a tiled window manager),

Exactly, for example, you've set your Windows key to be reponsible for all window-based movements, so you have it move/resize app windows and want to have the same key help you move/resize "inner windows/panes/columns" in a TUI app. Well, tough luck, the terminal doesn't even recognize this modifier!

Again, "as polish if you put in the effort" you can achieve anything via some external remapping to supported keys, but "otherwise" you don't have keybindings, and don't even have generalized fallback common (though not universal, again, there is no limit to garbage) to GUIs.

Or you'd be unable to bind some key combo because in a terminal that key combo is equivalent to regular typing and you need to timeout to differentiate between the two, so a permanent friction.

> tab is swallowed by an input so you can't even tab past a component

Of course you can, use your keyboard to move the mouse pointer and click outside of the input field. All pure organic keyboard-based interaction! "They could be garbage", but at lest you have that keyboard-based option (yes, only "polish/put in effort")

I've used some pretty bad ncurses apps that barely have keybindings, like oterm.

I'd probably put them in a third, discarded, mutant category where they are mouse-first applications that run in the terminal. Thus like GUIs, keyboard-support is bolted on.

So a better distinction here is mouse-first vs keyboard-first, but I think "TUI vs GUI" is close enough to that and it kinda stands in for that distinction in most cases.

Vim, tmux, and weechat would be examples of keyboard-first TUIs where mouse support is bolted on as polish, but never required.

Where you lose me is that every example you can think of where a bad TUI might not perfectly mesh into a keyboard-only workflow, the GUI counterparts to that example is much worse. So we would just agree that it's a bad TUI rather than anyone going "you're right, the average GUI is much better if keyboard-driven control is my priority".

I don't understand some of your examples though. Your super key is always at a global level that you wouldn't expect apps to read, that's the point. And using timeouts to handle keybinding collisions or something? Dunno what that looks like nor why you would do it. The examples are like if I said GUIs suck because it's a dreadful experience if you insist on using your mouse upside down.

> So a better distinction here is mouse-first vs keyboard-first, but I think "TUI vs GUI" is close enough to that and it kinda stands in for that distinction in most cases.

It's indeed a better distinction, but no, TUI vs GUI is nowhere close, specifically for your explicitly mentioned use case of "workflow is increasingly keyboard based" because that's exactly where GUI shines as it has much fewer fundamental limitations in keyboard handling.

> than anyone going "you're right, the average GUI

That's your strawman framing, why would I care about "the average"? It's not a limit for anyone, one can always choose a better-than-average app. My point is that at the top there is no comparison because TUIs offer nothing and have much bigger fundamental limitations. So of course with the wrong framing you can find worse examples.

> And using timeouts to handle keybinding collisions or something? Dunno what that looks like nor why you would do it.

Terminals send Esc for Alt-X combos, so to differentiate those combos from a single Escape press you need to track timers (if no extra key signal, then it's Esc, if another key signal, then it's a combo). And Esc is one of the most used keys in e.g. Vim

> Your super key is always at a global level that you wouldn't expect apps to read, that's the point.

Of course I would! What I wouldn't expect is for the app to override any global OS function bound to that key, but I would definitely expect to be able to not waste a whole thumb-conveniently located modifier just because

That's very close to my point - you're used to some trivial keyboard workflow, so wasting the whole modifier is just fine, you can't even comprehend why someone wouldn't want that, it's like a mouse upside down!

Maybe in theory, but in practice they literally all fail at that.

Every text editor and most professional apps have elaborate hotkey schemes in practice, though. It's a matter of target audience and developer intent. There's nothing special about TUIs in regards to keyboard driveability, and they're heavily limited in just about every single way I can think of. Which is the main reason most TUI apps are simple and small utilities.

The very nature of being simple makes it so that the amount of hotkeys you have to learn is limited.

While most gui ones also have hotkeys, most people only remember a tiny selection and have to rely on navigating menus and dialogs to access stuff they can't remember which makes their usage very slow.

It depends on the goal, e.g. software like Maya is built for the world in which the amount of required work makes even average projects intractable if you're slow with your tools. Entire generations of actual masters of their craft have built their careers on being efficient with it.

Menus are also not slow by any measure, they're only needed for discoverability, can be navigated with the keyboard as well, and aren't that different from the menus many TUI apps have (e.g. Midnight Commander). Moreover, there are real novel ideas like Microsoft's ribbon, which basically combine vi-style input and discoverability. Hotkeys is just one way to drive a GUI app using the keyboard, out of many.

IMO, the value in TUIs lie in 1) Composability: we've got really good tools for manipulating terminal windows like tmux, :term in vim, etc, whereas the same can't really be said for OS-level windows and 2) As a shibboleth: They implicitly state that they're built by and for keyboard-centric technical users, and thus the wants and needs of keyboard-centric technical users are going to be the valued over the wants and needs of the lowest common denominator. 3) They look cool.

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=== ---!

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.

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?

I think my low-key long-term goal is to eventually fully eliminate the mouse while still enjoying the niceties of a modern GUI desktop.

Going to shill for the Ultimate Hacking Keyboard here, specifically its mouse-keys capability, which is where I can move the mouse via WASD (or any other binding). I have both the touchpoint and trackball add-on modules, but I still use mouse keys to manipulate my cursor 99% of the time.