Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

As the article states:

> being compatible only with ANSI-capable terminals is a feature, not a bug

Driving old hardware terminals (as opposed to terminal emulators) is a fun stunt, not something of actual modern value. Every modern terminal emulator supports ANSI escape sequences. Some features are supported by a subset of terminals, but you can either 1) probe for those features by asking the terminal, which some terminals support, or 2) try them and have graceful degradation if they're not supported, or 3) have configuration options to use them, or 4) don't use them.

For every one case in which terminfo allows you to support some obscure non-ANSI terminal, there are many many more cases where terminfo won't happen to have a definition of the user's terminal (or won't know all the capabilities of the user's terminal) and you'll have less functionality than if you just used ANSI escapes. This is especially true over SSH and similar.

View on HN

You don't need terminfo until you need to redirect those fancy outputs to a file, or you see a lot of weird [M; in your CI logs, or your ssh session does not display full 256 colors, or you question why we don't have true images in our terminals when we have bitmap escape codes for decades now[1]. No terminal was created equal and never will. terminfo is about future as it is about the past.

Color ansi codes might be everywhere today, but that's no reason to disgrace terminfo, there are a ton of other features that need checking and are not universal.

[1]: https://en.wikipedia.org/wiki/Sixel

> until you need to redirect those fancy outputs to a file, or you see a lot of weird [M; in your CI logs

The application should be checking isatty by default, unless the user overrides that.

> or your ssh session does not display full 256 colors

I've most often seen this kind of thing because the remote end doesn't have the right terminfo entries for the local terminal.

> or you question why we don't have true images in our terminals when we have bitmap escape codes for decades now

Sixel, specifically, doesn't seem to have much support other than in xterm itself (as opposed to otherwise-xterm-compatible terminals). And other bitmap extensions are something that many terminals support autodiscovery for.

> No terminal was created equal and never will. terminfo is about future as it is about the past.

Part of the problem is that terminfo doesn't have much info about the future, as opposed to the past.

For going beyond terminfo, I think autodiscovery protocols would be a better future path.

Plus a lot of interesting things aren't mentioned in terminfo - bracketed paste, cursor shaping, synchronized output, ...

And even truecolor was added to it about 10 years after terminals started gaining support.

And many terminals just claim to be "xterm-256color".

>2) try them and have graceful degradation if they're not supported

Note: There are many cases where degradation isn't graceful. Many terminals on windows currently spew garbage on your screen if you send bracketed paste (alacritty, for instance).

>1) probe for those features by asking the terminal, which some terminals support

This requires waiting for a reply, which often isn't useful. E.g. if you want synchronized output, you want it from the very first paint (because that's when the terminal is most likely to still be resized, e.g. by a tiling window manager). So you would have to delay your startup until you've either gotten a reply or "enough" time has passed that you believe it's not supported.

Frankly, this is all a big mess and terminfo isn't very helpful, but we don't have a good alternative either.

> Every modern terminal emulator supports ANSI escape sequences

Is this true on Windows? My understanding is that quite a few TUI libraries don't have windows support.

This is true for the new Windows terminal, which is more-or-less xterm compatible.

Reply on news.ycombinator.com