TUIs are awesome, because they can be deterministic or atomic (I don't know - please comment) - when you can press a series of commands and it will be processed till the end with predictable results. Except that terminal emulators are not deterministic - any program can break the state of the terminal. Read on.
How terminals are killing Windows refugees?
Do you know why people are opening terminals? First execute some commands, like launching server or installing some stuff. Logout with Ctrl-D and save files with Ctrl-S. And what happens if you accidentally press Ctrl-S in Linux terminal (which by default runs bash) is that the terminal will freeze and you won't even notice that you pressed Ctrl-S by mistake.
What can be worse than freezing interface. Do you remember last time you game, phone or browser froze? Probably not so fast, or at least you know the problem - memory or slow pages. Here nothing tells you that this is by design.
Terminal emulators don't know anything about shortcuts, key down and key up
Not only terminal emulators emulate ancient pieces of hardwire, they also just transmit symbols. You don't get "events" there. No key presses, no key combinations. You also need to "emulate" them by measuring time from one letter to another to see if that's possibly a shortcut. That's why terminals are slow by definition and not atomic - instead of checking keyboard state and signalling it, they just pass chars into wire. That's why you can not use vim in NORMAL mode with Russian layout, for example. It won't be the key 'i' passed when you press a physical keyboard button, it will be char 'ш' and vim doesn't know how to process it. There is no way to read key press or release in terminal emulators. You may wonder - how does it transmit keys like Ctrl, Alt, F1 etc. It encodes them in sequences of chars. And the sequence can be different length. To know which key will it be - Esc of F1, you need again to wait. It may sound crazy, but I just realized that terminal emulators may even add artificial delays between sequences to make sure receiving side can read the difference. Slow by design, again.
Drawbacks of going from two-wire terminal model
Terminals emulators were great (and still are), because of only one awesome feature - you can run them over any two wires. One input and one output. This is how you look into boot problems with your RPi or problems with other hardware. Very awesome, but for doing a shortcut based productivity booster in console, the underlying mechanism is just wrong. If you can not make a hot seat mortal kombat game in your interface, that interfaces not a human oriented.
Why a separate TUI interface is needed
I am DevOps. Meaning I spent a lot of time in console doing thing, and I really miss shortcuts and fast response time from this interface. There are a lot of visual text mode tools like dive that really help and save a lot of time instead of remembering and typing hundreds of commands that I need almost every day. But even TUI frameworks can not fix terminal problems leading to proliferation of the frameworks, but no solution.
abitrolly
commented
4 years ago
TUIs are awesome, because they can be deterministic or atomic (I don't know - please comment) - when you can press a series of commands and it will be processed till the end with predictable results. Except that terminal emulators are not deterministic - any program can break the state of the terminal. Read on.
How terminals are killing Windows refugees?
Do you know why people are opening terminals? First execute some commands, like launching server or installing some stuff. Logout with
Ctrl-Dand save files withCtrl-S. And what happens if you accidentally pressCtrl-Sin Linux terminal (which by default runsbash) is that the terminal will freeze and you won't even notice that you pressedCtrl-Sby mistake.What can be worse than freezing interface. Do you remember last time you game, phone or browser froze? Probably not so fast, or at least you know the problem - memory or slow pages. Here nothing tells you that this is by design.
Terminal emulators don't know anything about shortcuts, key down and key up
Not only terminal emulators emulate ancient pieces of hardwire, they also just transmit symbols. You don't get "events" there. No key presses, no key combinations. You also need to "emulate" them by measuring time from one letter to another to see if that's possibly a shortcut. That's why terminals are slow by definition and not atomic - instead of checking keyboard state and signalling it, they just pass chars into wire. That's why you can not use
vimin NORMAL mode with Russian layout, for example. It won't be the key 'i' passed when you press a physical keyboard button, it will bechar 'ш'andvimdoesn't know how to process it. There is no way to read key press or release in terminal emulators. You may wonder - how does it transmit keys like Ctrl, Alt, F1 etc. It encodes them in sequences of chars. And the sequence can be different length. To know which key will it be - Esc of F1, you need again to wait. It may sound crazy, but I just realized that terminal emulators may even add artificial delays between sequences to make sure receiving side can read the difference. Slow by design, again.Drawbacks of going from two-wire terminal model
Terminals emulators were great (and still are), because of only one awesome feature - you can run them over any two wires. One input and one output. This is how you look into boot problems with your RPi or problems with other hardware. Very awesome, but for doing a shortcut based productivity booster in console, the underlying mechanism is just wrong. If you can not make a hot seat mortal kombat game in your interface, that interfaces not a human oriented.
Why a separate TUI interface is needed
I am DevOps. Meaning I spent a lot of time in console doing thing, and I really miss shortcuts and fast response time from this interface. There are a lot of visual text mode tools like
divethat really help and save a lot of time instead of remembering and typing hundreds of commands that I need almost every day. But even TUI frameworks can not fix terminal problems leading to proliferation of the frameworks, but no solution.Where to go from here
We can have the best parts from the many worlds
moshas well)It is quite exciting if we could get back to next version discrete mouseless world. Think of minecraft at your 10 fingertips in 2D.