5 ms·

> Do you still need terminfo? It depends. If you just want to style some text and maybe do some basic cursor operations: probably not. If you want to use more a

> Do you still need terminfo? It depends. If you just want to style some text and maybe do some basic cursor operations: probably not. If you want to use more advanced operations or read key input: probably yes. I disagree. The vast majority of terminals will send the same sequences. There is almost never a case where handling the two options for backspace the same way will result in a bad user experience. What complicates this even more is that many terminals allow the user to modify which sequence the `Backspace` key sends (0x08 vs 0x7F). Any application relying on terminfo, where a user did not modify their terminfo entry, will interpret these wrong if a user has manually changed it. Terminfo is not needed anymore. It served a purpose to let applications know how to talk to a terminal. That era is gone.

arp242 2y ago
Hence "or read key input". And: > Key input handling is kind of a mess, and this is where I really recommend using a terminfo library if at all possible. This also avoids the whole backspace/delete key confusion (less of an issue today than it used to be, but still exists). Of course lots of applications don't use backspace or delete; sometimes you just want the ability to select between 3 items with j/k and arrow keys, or something like that. And if this is something just for yourself or a limited audience then it's fine to just read that from stdin and not worry too much.
- kragen 2y ago
  you are replying to a comment which specifically explains why it disagrees with the text you quoted from your essay; what is the point of repeating it? if someone found it unconvincing the first time, or found rockorager's rebuttal to it convincing, hopefully a mere repetition of your comment will not change that. and, if they found it convincing the first time and found rockorager's rebuttal unconvincing, repeating it is unnecessary
- rockorager 2y ago
  I guess my point is that even for key input, you don't need terminfo. Modern terminals, and I would agree with your definition of that, all use the same keyboard encodings. There is the notable case of backspace/delete you mentioned but as I said - you can treat both as a backspace press. All of that said, I am a huge proponent of the kitty keyboard protocol. I would love to live in a world where the "default" encoding of keys is done with the that protocol (with the disambiguate flag on)
  - arp242 2y ago
    > I guess my point is that even for key input, you don't need terminfo. Right, I read that the other way round ("no, you do need terminfo for key input")! For basic input it's fairly straight-forward, and even for various "special" keys like arrows and function keys it's not too bad: just check from a list. But with modifier keys it gets more tricky; lots of that isn't even in terminfo and requires "special" handling. If you know how this works and you know what you're doing it can be fine, but for most people it's far easier to just use a terminfo library that does this for you. And yeah, Kitty keyboard protocol being the default would be brilliant. Right now support is (far) too flaky though, so maybe in 5 to 10 years.
somat 2y ago
Gotta admit I still have ptsd from working with a company that invested big in WYSE terminals early on. We were trying to switch over to terminal emulators and really wanted to just use one of the myriad of vt100 emulators avialable. Every single day was a different variant of "wtf is this. I wish they had just used terminfo" So I don't know how needed it is anymore. But I will have a hard time giving up terminfo and going over to the darkside.
- Brian_K_White 2y ago
  Agreed. I never understand the argument that we should forget that we solved a problem. Most terminals today are mostly vt-like? So the F what? Whether anyone likes it or not, or beleives it or not because of their own limited direct personal experience, the problem that termcap/terminfo worked around still exists today. Since the problem still exists, the solution (or I would call it more of a work-around) is still required. Simply pretending or ignoring doesn't resolve anything. When some spec becomes a decreed standard that you can actually count on, like we take one of the many vt-alikes and enshrine that one and all terminals are actually required to impliment that spec exactly, then you can maybe talk about "we don't need termcap or terminfo any more, it's ok to hard-code this spec from now on" And I won't even start on all the things wrong with "just map both to up arrow" holy cow.
  - follower 2y ago
    > And I won't even start on all the things wrong with "just map both to up arrow" holy cow. Could you humour us with just a couple of the things wrong with it? Cos I'm certainly interested to learn more about it. :)
kragen 2y ago
i mostly agree. if you want to run an application that assumes ansi escape sequence support and a terminal emulator that doesn't implement ansi escape sequences, you can run a terminal emulator inside your terminal emulator, with the inner terminal emulator interpreting the ansi escape sequences and talking to the outer terminal emulator with whatever escape codes the outer one uses three options for this inner terminal emulator are gnu screen (previously iscreen, which was a better name), tmux, and emacs term-mode. all three of these can use terminfo to figure out how to manipulate the outer terminal—but they wouldn't have to. mosh also does this terminal-emulator-inception thing but i think it's hardcoded to use ansi escape sequences to draw — ⁂ — what i'd really like to see is a reimagining of the terminal interface as something better than a vt340+. we have lots of historical things that could be sort of described that way (genera's lisp listener, the blit, mgr, caleb winston's stdg, notty, x11, postscript, html, react, wayland, opengl, vulkan, vnc) but they all fall short in one way or another. minimally i want a user interface that i can 1. write programs for in any programming language such that 2. simple programs like 'hello, world' or displaying a two-column table of numbers are about as simple as in an xterm, and 3. the programs' input and output is manipulable by the user at various levels of abstraction (copy/paste, screenshots, editing the output text, automating interactive workflows (like expect/autohotkey/selenium), screen readers, asciinema/screencasting, livestreaming, obs studio), and 4. the program is interactive (html kind of fails at this), and 5. the user interface can be used on a separate computer from the program (maybe the user interface runs on a cellphone while the program runs on a rack in a data center, or maybe the user interface runs on a laptop while the program runs on a quadcopter), and 6. small computers (under a megabyte of ram) can be used to show the program's user interface, but 7. the program can display anything the user's monitor is physically capable of displaying and support any of the user's input devices, including mice, touchscreens, accelerometers, cameras, etc. emulating a vt340+ like xterm does gives you the first six of these, which is a big reason why people keep writing new programs for that platform, but totally flunks the last one; you can't even display text in a proportional font, much less a photo or a video obviously there's some degree of tradeoff in some cases between 5, 6, and 7, because you aren't going to stream 4k video over a 9600-baud serial line, and you aren't going to decode it on a 286 (nor are you going to stream webcam video back from the user if the webcam is plugged into a 286), but there's a pretty broad spectrum today of {comms bandwidth, terminal cpu, desired output} triples for which performance isn't a hard problem—all you have to do is not totally fuck it up like sixel i don't know, i'm not waiting around, i'm gonna be over here hacking on godot instead
akira2501 2y ago
> The vast majority of terminals will send the same sequences. Not for function keys in particular not for the modifiers. Just take a look at the output of 'infocmp' between your favorite terminal and your favorite terminal with tmux running in it or even just a different terminal itself. Another issue is knowing capabilities, total number of colors, allowed attributes, default state of attributes, allowed actions when certain attributes are enabled or disabled. There's about half of the definitions which are common across almost all modern terminals, and the other half are unique and describe unique implementation details of the emulator.
- tedunangst 2y ago
  There aren't that many conflicts, really. Is the up arrow escOA or esc[A? Doesn't matter. If you're reading from terminal, just map both to up.

arp242 2y ago

Hence "or read key input". And: > Key input handling is kind of a mess, and this is where I really recommend using a terminfo library if at all possible. This also avoids the whole backspace/delete key confusion (less of an issue today than it used to be, but still exists). Of course lots of applications don't use backspace or delete; sometimes you just want the ability to select between 3 items with j/k and arrow keys, or something like that. And if this is something just for yourself or a limited audience then it's fine to just read that from stdin and not worry too much.

kragen 2y ago
you are replying to a comment which specifically explains why it disagrees with the text you quoted from your essay; what is the point of repeating it? if someone found it unconvincing the first time, or found rockorager's rebuttal to it convincing, hopefully a mere repetition of your comment will not change that. and, if they found it convincing the first time and found rockorager's rebuttal unconvincing, repeating it is unnecessary
rockorager 2y ago
I guess my point is that even for key input, you don't need terminfo. Modern terminals, and I would agree with your definition of that, all use the same keyboard encodings. There is the notable case of backspace/delete you mentioned but as I said - you can treat both as a backspace press. All of that said, I am a huge proponent of the kitty keyboard protocol. I would love to live in a world where the "default" encoding of keys is done with the that protocol (with the disambiguate flag on)
- arp242 2y ago
  > I guess my point is that even for key input, you don't need terminfo. Right, I read that the other way round ("no, you do need terminfo for key input")! For basic input it's fairly straight-forward, and even for various "special" keys like arrows and function keys it's not too bad: just check from a list. But with modifier keys it gets more tricky; lots of that isn't even in terminfo and requires "special" handling. If you know how this works and you know what you're doing it can be fine, but for most people it's far easier to just use a terminfo library that does this for you. And yeah, Kitty keyboard protocol being the default would be brilliant. Right now support is (far) too flaky though, so maybe in 5 to 10 years.

somat 2y ago

Gotta admit I still have ptsd from working with a company that invested big in WYSE terminals early on. We were trying to switch over to terminal emulators and really wanted to just use one of the myriad of vt100 emulators avialable. Every single day was a different variant of "wtf is this. I wish they had just used terminfo" So I don't know how needed it is anymore. But I will have a hard time giving up terminfo and going over to the darkside.

Brian_K_White 2y ago
Agreed. I never understand the argument that we should forget that we solved a problem. Most terminals today are mostly vt-like? So the F what? Whether anyone likes it or not, or beleives it or not because of their own limited direct personal experience, the problem that termcap/terminfo worked around still exists today. Since the problem still exists, the solution (or I would call it more of a work-around) is still required. Simply pretending or ignoring doesn't resolve anything. When some spec becomes a decreed standard that you can actually count on, like we take one of the many vt-alikes and enshrine that one and all terminals are actually required to impliment that spec exactly, then you can maybe talk about "we don't need termcap or terminfo any more, it's ok to hard-code this spec from now on" And I won't even start on all the things wrong with "just map both to up arrow" holy cow.
- follower 2y ago
  > And I won't even start on all the things wrong with "just map both to up arrow" holy cow. Could you humour us with just a couple of the things wrong with it? Cos I'm certainly interested to learn more about it. :)

kragen 2y ago

i mostly agree. if you want to run an application that assumes ansi escape sequence support and a terminal emulator that doesn't implement ansi escape sequences, you can run a terminal emulator inside your terminal emulator, with the inner terminal emulator interpreting the ansi escape sequences and talking to the outer terminal emulator with whatever escape codes the outer one uses three options for this inner terminal emulator are gnu screen (previously iscreen, which was a better name), tmux, and emacs term-mode. all three of these can use terminfo to figure out how to manipulate the outer terminal—but they wouldn't have to. mosh also does this terminal-emulator-inception thing but i think it's hardcoded to use ansi escape sequences to draw — ⁂ — what i'd really like to see is a reimagining of the terminal interface as something better than a vt340+. we have lots of historical things that could be sort of described that way (genera's lisp listener, the blit, mgr, caleb winston's stdg, notty, x11, postscript, html, react, wayland, opengl, vulkan, vnc) but they all fall short in one way or another. minimally i want a user interface that i can 1. write programs for in any programming language such that 2. simple programs like 'hello, world' or displaying a two-column table of numbers are about as simple as in an xterm, and 3. the programs' input and output is manipulable by the user at various levels of abstraction (copy/paste, screenshots, editing the output text, automating interactive workflows (like expect/autohotkey/selenium), screen readers, asciinema/screencasting, livestreaming, obs studio), and 4. the program is interactive (html kind of fails at this), and 5. the user interface can be used on a separate computer from the program (maybe the user interface runs on a cellphone while the program runs on a rack in a data center, or maybe the user interface runs on a laptop while the program runs on a quadcopter), and 6. small computers (under a megabyte of ram) can be used to show the program's user interface, but 7. the program can display anything the user's monitor is physically capable of displaying and support any of the user's input devices, including mice, touchscreens, accelerometers, cameras, etc. emulating a vt340+ like xterm does gives you the first six of these, which is a big reason why people keep writing new programs for that platform, but totally flunks the last one; you can't even display text in a proportional font, much less a photo or a video obviously there's some degree of tradeoff in some cases between 5, 6, and 7, because you aren't going to stream 4k video over a 9600-baud serial line, and you aren't going to decode it on a 286 (nor are you going to stream webcam video back from the user if the webcam is plugged into a 286), but there's a pretty broad spectrum today of {comms bandwidth, terminal cpu, desired output} triples for which performance isn't a hard problem—all you have to do is not totally fuck it up like sixel i don't know, i'm not waiting around, i'm gonna be over here hacking on godot instead

akira2501 2y ago

> The vast majority of terminals will send the same sequences. Not for function keys in particular not for the modifiers. Just take a look at the output of 'infocmp' between your favorite terminal and your favorite terminal with tmux running in it or even just a different terminal itself. Another issue is knowing capabilities, total number of colors, allowed attributes, default state of attributes, allowed actions when certain attributes are enabled or disabled. There's about half of the definitions which are common across almost all modern terminals, and the other half are unique and describe unique implementation details of the emulator.

tedunangst 2y ago
There aren't that many conflicts, really. Is the up arrow escOA or esc[A? Doesn't matter. If you're reading from terminal, just map both to up.