3 ms·

I was aware of the ANSI escape sequences and even used them directly in scripts on occasion, but I still used ncurses "where it mattered" because I didn't know

I was aware of the ANSI escape sequences and even used them directly in scripts on occasion, but I still used ncurses "where it mattered" because I didn't know about compatibility. I didn't want to risk Windows or a random flavor of linux I'd never heard of or a group of anti-VT100 enthusiasts getting upset because I didn't use an agreed upon compatibility layer. From the tone of this piece I gather that the ANSI escape codes are actually standard enough to target. Cool! Thanks for the heads up.

Beltalowda 4y ago
> From the tone of this piece I gather that the ANSI escape codes are actually standard enough to target. termfo[1] comes with a "termfo" CLI utility which – among other things – can group terminals by escape code; for example "termfo find-cap save_cursor" shows that almost all terminals use "\x1b7", with just a few very old ones using something different (full output is a bit long, but it's at [2]). It's useful to check "can I safely hard-code this escape code?" But like you said: for ANSI it's pretty safe to just hard-code most codes, especially the common ones, but never hurts to check. [1]: https://github.com/arp242/termfo https://github.com/arp242/termfo [2]: https://pastebin.com/raw/pVHGR6aZ https://pastebin.com/raw/pVHGR6aZ
duskwuff 4y ago
> From the tone of this piece I gather that the ANSI escape codes are actually standard enough to target. Correct. Hardware terminals are extinct in the wild, and essentially all software terminals (including the Windows terminal!) now support a reasonable subset of "extended VT100" terminal control sequences. Some of the weirder features of the VT100 (like double-high/double-wide text or VT52 compatibility mode) are usually omitted, and some features which were added in later DEC terminals (like color) are often added.
- GekkePrutser 4y ago
  The different features omitted and added are precisely one of the reasons you'd still want to be using an abstraction library. Otherwise you end up having to stick with the lowest common denominator, or having the user figure out how to enable each terminal feature in every app individually. These libraries were invented with good reason. Even now there's big differences between terminal emulators. Especially when you take modern features like images into account, there's like 6 different ways of doing it as some terminals have invented their own (kitty for one) and there's more standard ones like sixels which come originally from the Dec VT340 series. Though they were ridiculously slow on that hardware so it didn't take off until much later.
  - duskwuff 4y ago
    I feel like this depends a bit on what you consider to be "big differences", and what sort of abstraction library you have in mind. So long as you're only concerned with placing and formatting characters on the screen, support for the subset of "extended VT100" which is required is essentially universal. There is no disagreement over what escape sequences can be used to move the cursor, for example, or to clear the screen. Using an abstraction layer like termcap is effectively a no-op here; it will output the exact same sequences for any modern terminal application. And if you want to support modern and/or esoteric features like embedded graphics or custom characters ("sixels"), you're probably going to handcraft that anyway, as support for those features is very limited, and most abstraction libraries won't support them at all. So I'm not sure I see the case for an abstraction at either end of the spectrum.
- account42 4y ago
  > including the Windows terminal! Only since Windows 10 version 1511 (released 2015) which may or may not be too recent for you to assume support.

Beltalowda 4y ago

> From the tone of this piece I gather that the ANSI escape codes are actually standard enough to target. termfo[1] comes with a "termfo" CLI utility which – among other things – can group terminals by escape code; for example "termfo find-cap save_cursor" shows that almost all terminals use "\x1b7", with just a few very old ones using something different (full output is a bit long, but it's at [2]). It's useful to check "can I safely hard-code this escape code?" But like you said: for ANSI it's pretty safe to just hard-code most codes, especially the common ones, but never hurts to check. [1]: https://github.com/arp242/termfo https://github.com/arp242/termfo [2]: https://pastebin.com/raw/pVHGR6aZ https://pastebin.com/raw/pVHGR6aZ

duskwuff 4y ago

> From the tone of this piece I gather that the ANSI escape codes are actually standard enough to target. Correct. Hardware terminals are extinct in the wild, and essentially all software terminals (including the Windows terminal!) now support a reasonable subset of "extended VT100" terminal control sequences. Some of the weirder features of the VT100 (like double-high/double-wide text or VT52 compatibility mode) are usually omitted, and some features which were added in later DEC terminals (like color) are often added.

GekkePrutser 4y ago
The different features omitted and added are precisely one of the reasons you'd still want to be using an abstraction library. Otherwise you end up having to stick with the lowest common denominator, or having the user figure out how to enable each terminal feature in every app individually. These libraries were invented with good reason. Even now there's big differences between terminal emulators. Especially when you take modern features like images into account, there's like 6 different ways of doing it as some terminals have invented their own (kitty for one) and there's more standard ones like sixels which come originally from the Dec VT340 series. Though they were ridiculously slow on that hardware so it didn't take off until much later.
- duskwuff 4y ago
  I feel like this depends a bit on what you consider to be "big differences", and what sort of abstraction library you have in mind. So long as you're only concerned with placing and formatting characters on the screen, support for the subset of "extended VT100" which is required is essentially universal. There is no disagreement over what escape sequences can be used to move the cursor, for example, or to clear the screen. Using an abstraction layer like termcap is effectively a no-op here; it will output the exact same sequences for any modern terminal application. And if you want to support modern and/or esoteric features like embedded graphics or custom characters ("sixels"), you're probably going to handcraft that anyway, as support for those features is very limited, and most abstraction libraries won't support them at all. So I'm not sure I see the case for an abstraction at either end of the spectrum.
account42 4y ago
> including the Windows terminal! Only since Windows 10 version 1511 (released 2015) which may or may not be too recent for you to assume support.