Safe Terminal Escape Codes

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.

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.

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

> 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.

The hope is to eventually remove the in-kernel terminal emulator. See here https://dvdhrm.wordpress.com/2012/08/12/killing-off-config_v...

BTW, with regard to specifying "true" RGB colour related escape codes, note that there's currently a couple of... "issues" with the content in this section: https://www.arp242.net/safeterm.html#true-colours

1. The format of the escape codes given for "True color" is "incorrect"[0], as it "should"[1] use `:` as the separator between the individual red, green & blue values supplied.

2. There is a minor typo/copypesto in "Foreground", where "R" is incorrectly listed twice and "G" is missing.

--- footnotes ---

[0] By "incorrect", I mean "not spec compliant", however, given the author expresses a sentiment of/preference for "I don’t care what some spec says; I care about what works" this presumably motivates their inclusion of the "non spec compliant" form in preference to the strictly spec compliant form[2]. :)

[1] The TLDR being that the entire colour specified by the "RGB" values is a "parameter" (and thus should be separated/surrounded by ";") but the individual "R", "G", "B" values are "parameter sub-strings" (a.k.a. "sub-parameters") and thus "need" to use a different separator: ":", the parameter sub-string separator.

However, for reasons[3], historically ";" was initially incorrectly used by some terminal emulators ("xterm", in particular) as both the parameter separator and the parameter sub-string separator. This error was apparently eventually discovered & corrected in xterm but the correction was not necessarily implemented/propagated to other existing/new terminal emulator implementations--or other tools that parse or generate the colour-related escape codes[4].

[2] This sentiment/preference is not shared by everyone, however, for example, the developer of WezTerm notes in its escape code reference documentation: "The colon form is unambiguous and should be preferred; the semicolon form should not be used by new applications and is not documented here in the interest of avoiding accidental new implementations"[8]. :)

[3] Money, or rather, lack thereof. The reason for the original error has been explained as "We [incorrectly] used semicolon [...] for separating the R/G/B values in the escape sequence, since a copy of [the related standard/specification] which presumably clarified the use of colon for this feature was costly."[5][6]

[4] The distinction between use of ";" vs ":" is also not only of "academic"/historic relevance--within the past month (while developing a customization[9] for WezTerm) I ran into an issue caused by spec-compliant vs non-spec-compliant implementations[7] between WezTerm (which generated spec-compliant colour escape codes) and at least some version(s) of `journalctl` which failed to parse & display a log message formatted with the spec-compliant colour and instead displays `[89B blob data]` (by default). This necessitated "munging" the correct escape codes into an incorrect abomination[10] in order for the log message to be formatted & displayed as intended by `journalctl`.

[5] See: https://invisible-island.net/xterm/xterm.faq.html#color_by_n...

[6] For the "Too Long; Did Write:" version of the explanation see the two comments I wrote a year ago when I last fell into this particular rabbit hole, :D here: https://news.ycombinator.com/item?id=35157058 (When the digging leads to learning about the connections to conventions originating in the era of telegraph operators & Morse code, it's probably time to turn around. :D )

[7] To me this suggests one reason to continue using terminfo as a layer of abstraction even when e.g. "all current terminal emulators do the same thing", is that it's one way to reduce the risk of unintentional future deviations in behaviour by existing or new terminal implementations.

[8] The WezTerm escape code reference document is another useful resource for terminal escape code information (written from the perspective of an implementer) that also links to similar reference documents both for other terminal emulator implementations & an attempt to "catch them all": https://wezfurlong.org/wezterm/escape-sequences.html

[9] Reimplementing the Mac Terminal.app ability to display a "faded" scrollback history/context for each tab when restoring a terminal "session"--which is one of only a couple of things that I miss since moving from Mac to Linux as my primary computing environment.

[10] Which was obviously--being the "person of a certain disposition" that I am--both deeply upsetting, and, just, wrong. :D

what, are you going to do rowhammer in ansi?

There are, for iTerm2 for example: https://www.cvedetails.com/vulnerability-list/vendor_id-1701...

To not pick on iTerm2, the problem isn't iTerm2 in general (except for some of it), but the "standards" per say sorta assume trusted terminals, which made sense for VTNNN, but not so much since the internet started existing.

For all practical matters it is xterm that has become the standard.

Like with web browsers, it is irrelevant what the standard states. The only thing that matters is that it displays correctly with the most popular / authoritative browser.