4 ms·

Digging around in terminfo is like holding a flickering, flaming torch up to some hieroglyphics in some deep catacomb. It's weird to think just how much complex

Digging around in terminfo is like holding a flickering, flaming torch up to some hieroglyphics in some deep catacomb. It's weird to think just how much complexity goes into a terminal application. Makes me even more grateful to the devs behind iTerm and Kitty (and all the others!) EDIT: for iTerm+zsh, I collected some functions for setting tab colors: https://gist.github.com/aclarknexient/84ebe33c1879f92168530487528802c4 https://gist.github.com/aclarknexient/84ebe33c1879f921685304... EDIT2: Contrast terminfo with the old-school method of connecting to HTTP or SMTP with telnet. Yeah, it's simple text but that text is being displayed by a complex application that supports all sorts of wild stuff!

vidarh 3y ago
I use my own terminal, and early made the decision not to give a shit about terminfo, pretend to be rxvt, and deal with the fallout (now, admittedly, the only user I care about for my terminal is me - at least for now). Modern terminals supports enough of a shared subset that it's less painful doing that than having to deal with applications get all confused because they don't recognize your TERM variable, to the point where I've typically found the closest match whenever I've used a less common terminal in the past too. (This matters less if you don't regularly ssh into new systems, of course)
- bloopernova 3y ago
  That's fascinating! Did you have a specific itch you wanted to scratch by writing your own terminal? Or was it a learning project that you found useful?
  - vidarh 3y ago
    A combination of a procrastination project, wanting a pure Ruby library I can use for output from hybrid applications (e.g. my editor) to be able to have a mostly terminal UI but being able to add in limited graphics when available, and wanting a testbed for other terminal changes I want to experiment with in terms of creating more of a hybrid UI. A basic terminal can be fairly small - mine is ~1800 lines of Ruby at the moment, which I consider disappointingly large. For comparison st is ~8k lines, I think, and xterm is ~88k. But you can do a working terminal in far less than my 1800, even in more verbose languages, so it's a nice space to play in where you can get something that works in very little (set TERM to a dumber terminal than rxvt, dump any escape sequences your terminal doesn't yet understand to a log, and run the apps you need, then iterate...), and build up in whichever direction you want to something quite usable very quickly. Then you can spend a lifetime polishing quirky little details nobody with you will ever care about... ;)
- kps 3y ago
  > pretend to be rxvt, and deal with the fallout (now, admittedly, the only user I care about for my terminal is me - at least for now It's fine when it's just you. Unfortunately, there are some widely used terminals that default to claiming to be xterm, but are not xterm compatible.
  - vidarh 3y ago
    Frankly, I find most work well enough with xterm or rxvt termcaps to prefer that over having apps just refuse to even try to work until you've changed settings. But conversely, if distributed like that, I'd also feel that this implicitly means any failure to act like xterm is a bug they've implicitly suggested it is reasonable to report or complain about (and if the version number doesn't imply it's an early stage release, and it still doesn't work well with its defaults, I'd get cranky)
  - o11c 3y ago
    If you send feature-detection queries it doesn't matter. The nasty part is that RXVT violates ISO 2022 structure in weird ways. It's not alone in that, but most of the other-program violations are much more easily fixed.
- tambourine_man 3y ago
  I’d like to know more of the motivations for building your own terminal. Are you using a library or written all from scratch?
  - vidarh 3y ago
    See a lengthier reply elsewhere in this thread, re: motivations etc. but it's almost all from scratch. Frankly, a simple terminal is not a huge amount of work, and you can get something working "well enough" to start with with very little code. The huge amount of work comes from nailing all the quirks you will have to deal with if you let a bunch of other users loose on it, with their expectations of running all kinds of applications I've never tested that does weird stuff.
    - tambourine_man 3y ago
      Yeah, the last 10%. I saw your reply after posting mine, thanks.
      - ddingus 3y ago
        Famously the last 90% of the project :(
- JoshTriplett 3y ago
  Absolutely agreed. The main problem with that is providing new features that xterm doesn't support, but terminfo pretty much refuses to add new features anyway, so modern terminals have had to work around that with some combination of autodetection, separate environment variables, or YOLO approaches. So, at this point, I'm not sure it's worth supporting terminfo at all for most applications, either as a terminal emulator or as a CLI program. (The article makes a similar point about the negative value terminfo is providing for modern applications.) If you're building a program that takes over the terminal screen, you probably should use one of the established libraries that abstracts over terminfo and over old non-ANSI Windows consoles. But if you're doing light terminal handling in an application that doesn't take over the screen, such as emitting colors or doing simple cursor control, forget about terminfo and just handle two or three cases: ANSI, optionally old pre-ANSI Windows consoles, and files/terminals with no support for anything. Rounding ancient terminals or terminal emulators to "no support" and giving them the same thing you'd give a redirection to a file seems entirely reasonable for a new program.
  - bitwize 3y ago
    Just... please please please call isatty() and don't barf ANSI cruft into my buffers.
    - vidarh 3y ago
      I'd frankly far prefer people not to call isatty(), and require switches for machine-readable output. The kind of tools that "barf ANSI cruft" are usually the tools I want to do so even when I'm piping their output into something else. It's a real nuisance to e.g. deal with options to preserve colours through a pipe for every element. There might well be exceptions where I'd prefer to default to checking isatty(), but they are few. If there was any remotely standard way of signaling the preferred default, and a remotely standard command line option to toggle that default, it'd make things a lot nicer, because I totally understand where you're coming from; I get equally annoyed just in the opposite scenarios, so the situation is a nuisance for both of us.
      - 3y ago
- kabdib 3y ago
  When I was on ITS, I just implemented SUPDUP in my terminal. It made Emacs usable at 300 baud. That protocol is a nice piece of engineering. I got a big dose of Telecoms standards early in my career, including some X.25 and networking stuff. After the clarity and simplicity of SUPDUP, my reaction to Big Standards could best be described as "allergic". [Marshall Rose and Michael Padlipski are good reading on this subject. To this day I use the word "octet" as an epithet] use standards not too many mostly plain ones
liamwire 3y ago
Any chance you’d be willing to share some screenshots of the tab colours in action?
- bloopernova 3y ago
  Good point, I'll add some tomorrow.
- bloopernova 3y ago
  Here you go: https://gist.github.com/aclarknexient/84ebe33c1879f92168530487528802c4?permalink_comment_id=4863613#gistcomment-4863613 https://gist.github.com/aclarknexient/84ebe33c1879f921685304...
Affric 3y ago
iTerm is the software I miss most from Mac. Is not the fastest terminal emulator but it’s the best looking by miles.

vidarh 3y ago

I use my own terminal, and early made the decision not to give a shit about terminfo, pretend to be rxvt, and deal with the fallout (now, admittedly, the only user I care about for my terminal is me - at least for now). Modern terminals supports enough of a shared subset that it's less painful doing that than having to deal with applications get all confused because they don't recognize your TERM variable, to the point where I've typically found the closest match whenever I've used a less common terminal in the past too. (This matters less if you don't regularly ssh into new systems, of course)

bloopernova 3y ago
That's fascinating! Did you have a specific itch you wanted to scratch by writing your own terminal? Or was it a learning project that you found useful?
- vidarh 3y ago
  A combination of a procrastination project, wanting a pure Ruby library I can use for output from hybrid applications (e.g. my editor) to be able to have a mostly terminal UI but being able to add in limited graphics when available, and wanting a testbed for other terminal changes I want to experiment with in terms of creating more of a hybrid UI. A basic terminal can be fairly small - mine is ~1800 lines of Ruby at the moment, which I consider disappointingly large. For comparison st is ~8k lines, I think, and xterm is ~88k. But you can do a working terminal in far less than my 1800, even in more verbose languages, so it's a nice space to play in where you can get something that works in very little (set TERM to a dumber terminal than rxvt, dump any escape sequences your terminal doesn't yet understand to a log, and run the apps you need, then iterate...), and build up in whichever direction you want to something quite usable very quickly. Then you can spend a lifetime polishing quirky little details nobody with you will ever care about... ;)
kps 3y ago
> pretend to be rxvt, and deal with the fallout (now, admittedly, the only user I care about for my terminal is me - at least for now It's fine when it's just you. Unfortunately, there are some widely used terminals that default to claiming to be xterm, but are not xterm compatible.
- vidarh 3y ago
  Frankly, I find most work well enough with xterm or rxvt termcaps to prefer that over having apps just refuse to even try to work until you've changed settings. But conversely, if distributed like that, I'd also feel that this implicitly means any failure to act like xterm is a bug they've implicitly suggested it is reasonable to report or complain about (and if the version number doesn't imply it's an early stage release, and it still doesn't work well with its defaults, I'd get cranky)
- o11c 3y ago
  If you send feature-detection queries it doesn't matter. The nasty part is that RXVT violates ISO 2022 structure in weird ways. It's not alone in that, but most of the other-program violations are much more easily fixed.
tambourine_man 3y ago
I’d like to know more of the motivations for building your own terminal. Are you using a library or written all from scratch?
- vidarh 3y ago
  See a lengthier reply elsewhere in this thread, re: motivations etc. but it's almost all from scratch. Frankly, a simple terminal is not a huge amount of work, and you can get something working "well enough" to start with with very little code. The huge amount of work comes from nailing all the quirks you will have to deal with if you let a bunch of other users loose on it, with their expectations of running all kinds of applications I've never tested that does weird stuff.
  - tambourine_man 3y ago
    Yeah, the last 10%. I saw your reply after posting mine, thanks.
    - ddingus 3y ago
      Famously the last 90% of the project :(
JoshTriplett 3y ago
Absolutely agreed. The main problem with that is providing new features that xterm doesn't support, but terminfo pretty much refuses to add new features anyway, so modern terminals have had to work around that with some combination of autodetection, separate environment variables, or YOLO approaches. So, at this point, I'm not sure it's worth supporting terminfo at all for most applications, either as a terminal emulator or as a CLI program. (The article makes a similar point about the negative value terminfo is providing for modern applications.) If you're building a program that takes over the terminal screen, you probably should use one of the established libraries that abstracts over terminfo and over old non-ANSI Windows consoles. But if you're doing light terminal handling in an application that doesn't take over the screen, such as emitting colors or doing simple cursor control, forget about terminfo and just handle two or three cases: ANSI, optionally old pre-ANSI Windows consoles, and files/terminals with no support for anything. Rounding ancient terminals or terminal emulators to "no support" and giving them the same thing you'd give a redirection to a file seems entirely reasonable for a new program.
- bitwize 3y ago
  Just... please please please call isatty() and don't barf ANSI cruft into my buffers.
  - vidarh 3y ago
    I'd frankly far prefer people not to call isatty(), and require switches for machine-readable output. The kind of tools that "barf ANSI cruft" are usually the tools I want to do so even when I'm piping their output into something else. It's a real nuisance to e.g. deal with options to preserve colours through a pipe for every element. There might well be exceptions where I'd prefer to default to checking isatty(), but they are few. If there was any remotely standard way of signaling the preferred default, and a remotely standard command line option to toggle that default, it'd make things a lot nicer, because I totally understand where you're coming from; I get equally annoyed just in the opposite scenarios, so the situation is a nuisance for both of us.
    - 3y ago
kabdib 3y ago
When I was on ITS, I just implemented SUPDUP in my terminal. It made Emacs usable at 300 baud. That protocol is a nice piece of engineering. I got a big dose of Telecoms standards early in my career, including some X.25 and networking stuff. After the clarity and simplicity of SUPDUP, my reaction to Big Standards could best be described as "allergic". [Marshall Rose and Michael Padlipski are good reading on this subject. To this day I use the word "octet" as an epithet] use standards not too many mostly plain ones

liamwire 3y ago

Any chance you’d be willing to share some screenshots of the tab colours in action?

bloopernova 3y ago
Good point, I'll add some tomorrow.
bloopernova 3y ago
Here you go: https://gist.github.com/aclarknexient/84ebe33c1879f92168530487528802c4?permalink_comment_id=4863613#gistcomment-4863613 https://gist.github.com/aclarknexient/84ebe33c1879f921685304...

Affric 3y ago

iTerm is the software I miss most from Mac. Is not the fastest terminal emulator but it’s the best looking by miles.