If you’re at all interested in terminal history, I recommend poking at the terminfo database source code. Much like the tzdata database, it has a lot of comments describing how things came to be and why they are the way they are, alongside the actual definitions.
Neat, now I will have to go read the tzdata database! It was the terminfo database comments that, completely unexpectedly, helped me establish communication with an H19 Heathkit terminal years ago, by supplementing the dry machine-readable description of its escape codes with a delightful and complete summary of what its DIP switches configure.
# Here is a description of the H19 DIP switches: ...
# S402
# 0 = block cursor (0 = underscore cursor)
# 1 = no key click (0 = keyclick)
# 2 = wrap at end of line (0 = no wrap)
# 3 = auto LF on CR (0 = no LF on CR)
# 4 = auto CR on LF (0 = no CR on LF)
# 5 = ANSI mode (0 = VT52 mode)
# 6 = keypad shifted (0 = keypad unshifted)
# 7 = 50Hz refresh (1 = 60Hz refresh)
Getting agreement from all of the terminal emulator authors and their supporters is a political nightmare. For some reason people who write terminal emulators are more surly and churlish than average, IMHO. Egmont Koblinger (I think it was Egmont) has tried to create a version of the WHATWG for interested parties here https://gitlab.freedesktop.org/terminal-wg and basically burnt out trying. I might try to revive it in the Fall if I have some free time then
The WHATWG only had a couple of members that had roughly the same target audience and stood to benefit from cooperation.
Terminals are typically developed by hobbyists who have their own idiosyncratic ideas about How Things Should Be, and no real reason to change their mind. Being bug-compatible with another terminal won’t raise their stock-price or advertising revenue, but it will make them sad and take time away from implementing yet another image embedding system or a way to encode MIDI events.
I don’t see any kind of Terminal Working Group succeeding until somebody has a clear vision of what terminals can and should be, and does the hard work of building consensus in that direction… and a lot of the existing ideas about what terminals can and should be are violently contradictory, so building consensus would be very hard work indeed.
Chalk (JavaScript) maintainer here. I attempted to do this at one point several years ago and also gave up trying. I asked if I could even kick off PRs to integrate standards switches etc.
to alleviate some of the work. Was told flatly “no” by a few emulator maintainers.
I’m familiar with the deep history here, going back to BSD termcap in the 1980s and the System V terminfo stuff. In principle terminfo could have been better because it compiled the data into a binary format that could mostly be used directly, instead of having programs parse the entire termcap file every time. But like most binary formats it was fiddly and brittle and hard to deal with.
I’d mostly lost track of this stuff in the intervening years. It’s sad to see this stuff half-neglected and mostly unmaintained.
What’s new for me is that maybe this stuff isn’t necessary anymore. Maybe this approach is sufficient:
Identify a “single common set” of escape codes which works in “enough” terminal emulators and just hardcode those.
The days are gone of there being dozens of different terminal manufacturers whose terminals all had different escape sequences. If one were to write a new system that needs better terminal control, why bother with terminfo?
FWIW, the rant Julia links to is indeed well worth a read. And terminals are so old that except for specific examples & details, I think this rant could have been delivered 20 years ago in spirit.
The tendency to “lie and say you’re xterm” has been around for a least 25..30 years by now.. maybe longer. One way to express the situation today might be that we have “emulators of xterm” of various degrees of emulation fidelity and with various extensions.
For years, every time I installed emacs in a new box I spent hours mapping the extended keyboard to various keymaps, but I haven’t bothered lately. Now to get to end of line I press End, C-g, C-e.
If you’re at all interested in terminal history, I recommend poking at the terminfo database source code. Much like the tzdata database, it has a lot of comments describing how things came to be and why they are the way they are, alongside the actual definitions.
Neat, now I will have to go read the tzdata database! It was the terminfo database comments that, completely unexpectedly, helped me establish communication with an H19 Heathkit terminal years ago, by supplementing the dry machine-readable description of its escape codes with a delightful and complete summary of what its DIP switches configure.
https://github.com/ThomasDickey/ncurses-snapshots/blob/47462c410b0d49dacbb27ec79ff6dad81e3eb40b/misc/terminfo.src#L22862
Getting agreement from all of the terminal emulator authors and their supporters is a political nightmare. For some reason people who write terminal emulators are more surly and churlish than average, IMHO. Egmont Koblinger (I think it was Egmont) has tried to create a version of the WHATWG for interested parties here https://gitlab.freedesktop.org/terminal-wg and basically burnt out trying. I might try to revive it in the Fall if I have some free time then
The WHATWG only had a couple of members that had roughly the same target audience and stood to benefit from cooperation.
Terminals are typically developed by hobbyists who have their own idiosyncratic ideas about How Things Should Be, and no real reason to change their mind. Being bug-compatible with another terminal won’t raise their stock-price or advertising revenue, but it will make them sad and take time away from implementing yet another image embedding system or a way to encode MIDI events.
I don’t see any kind of Terminal Working Group succeeding until somebody has a clear vision of what terminals can and should be, and does the hard work of building consensus in that direction… and a lot of the existing ideas about what terminals can and should be are violently contradictory, so building consensus would be very hard work indeed.
Chalk (JavaScript) maintainer here. I attempted to do this at one point several years ago and also gave up trying. I asked if I could even kick off PRs to integrate standards switches etc. to alleviate some of the work. Was told flatly “no” by a few emulator maintainers.
I’m familiar with the deep history here, going back to BSD termcap in the 1980s and the System V terminfo stuff. In principle terminfo could have been better because it compiled the data into a binary format that could mostly be used directly, instead of having programs parse the entire termcap file every time. But like most binary formats it was fiddly and brittle and hard to deal with.
I’d mostly lost track of this stuff in the intervening years. It’s sad to see this stuff half-neglected and mostly unmaintained.
What’s new for me is that maybe this stuff isn’t necessary anymore. Maybe this approach is sufficient:
The days are gone of there being dozens of different terminal manufacturers whose terminals all had different escape sequences. If one were to write a new system that needs better terminal control, why bother with terminfo?
FWIW, the rant Julia links to is indeed well worth a read. And terminals are so old that except for specific examples & details, I think this rant could have been delivered 20 years ago in spirit.
The tendency to “lie and say you’re xterm” has been around for a least 25..30 years by now.. maybe longer. One way to express the situation today might be that we have “emulators of xterm” of various degrees of emulation fidelity and with various extensions.
For years, every time I installed emacs in a new box I spent hours mapping the extended keyboard to various keymaps, but I haven’t bothered lately. Now to get to end of line I press End, C-g, C-e.