Ask HN: ANSI escape sequences reference docs?
15 comments
It's mentioned already but needs to be mentioned again: start with https://vt100.net for DEC vt100-vt520 documentation.
Check out this comment by jart (cosmpolitan author) here: https://github.com/jart/cosmopolitan/issues/766#issuecomment...
it might help but not sure how comprehensive it is! would it be a bad idea for you to check out the source code of other popular emulators (maybe iTerm 2^0) ?
0: https://github.com/search?q=repo%3Agnachman%2FiTerm2%20ansi&...
it might help but not sure how comprehensive it is! would it be a bad idea for you to check out the source code of other popular emulators (maybe iTerm 2^0) ?
0: https://github.com/search?q=repo%3Agnachman%2FiTerm2%20ansi&...
I’ve using the source for other emulators as a reference for getting things like PTYs right. But I found them to be generally hard to grok for understanding the behaviours of the more esoteric escape sequences. Simple stuff like SGR is quite readable but there’s already a lot of documentation out there for SGR.
Thanks for the links, I’ll have a read through them
Thanks for the links, I’ll have a read through them
I used to program many different terminals, back when they were a thing.
A classic terminal only has a screen full of memory: it does have extra memory that would allow it to scroll backwards.
The ESC [ S command (CSI itself can only be used if you are sure the line to the terminal is 8-bit clean, and as a third-party developer, I could not guarantee that) scrolls the scrolling region. The scrolling region is either the entire screen, or it's just a couple of line at the bottom. A scrolling region is used so the use can have a scrolling place to type commands and Aldo have a non-scrolling area to display data.
A classic terminal only has a screen full of memory: it does have extra memory that would allow it to scroll backwards.
The ESC [ S command (CSI itself can only be used if you are sure the line to the terminal is 8-bit clean, and as a third-party developer, I could not guarantee that) scrolls the scrolling region. The scrolling region is either the entire screen, or it's just a couple of line at the bottom. A scrolling region is used so the use can have a scrolling place to type commands and Aldo have a non-scrolling area to display data.
Maybe look at specific terminal specs? Things like vt100 were actual devices, not mere conventions!
https://en.m.wikipedia.org/wiki/VT100
Though, I kinda suspect “xterm” is the defacto modern standard.
Though, I kinda suspect “xterm” is the defacto modern standard.
Even the VT100 didn't have a "spec" per se. The user manual [1] is a helpful reference, but is rather vague on the details. (In particular, some important details of how and when line wrapping occurs are not described in the manual.)
[1]: https://vt100.net/docs/vt100-ug/
[1]: https://vt100.net/docs/vt100-ug/
That’s what I have been doing. But terminal specs only cover supported escape sequences on that terminal and seldom cover how that sequence behaves in any detail.
https://iterm2.com/documentation-escape-codes.html
https://news.ycombinator.com/item?id=26011198
Also, search Hacker News for the links above.
https://news.ycombinator.com/item?id=26011198
Also, search Hacker News for the links above.
I am not convinced one very detailed spec describing such details you mention even exists. I guess if vim, emacs, and less work correctly you are close to done. Screen and tmux are others coming to mind.
All of them are open source, why don't you check how they end up emitting escape sequences? My guess would be through abstraction via something like terminfo/termcap. Ncurses might be another place to look at.
Don't forget about dynamic resizing from day one. That won't be mentioned in old documents from the VT100 times. Don't remember which VT was the first one that could be switch to 132(?) characters a line.
All of them are open source, why don't you check how they end up emitting escape sequences? My guess would be through abstraction via something like terminfo/termcap. Ncurses might be another place to look at.
Don't forget about dynamic resizing from day one. That won't be mentioned in old documents from the VT100 times. Don't remember which VT was the first one that could be switch to 132(?) characters a line.
Funny enough, I’ve been using tmux as my benchmark. Good idea about testing the other tools. I found BSD ‘top’ particularly troublesome too because that uses alternative character sets to do the line art.
The dynamic resizing is something I’ve decided to relegate to later in the project. Hopefully that decision doesn’t bite me and m the arse but I haven’t a clue how I’d approach that problem right now
The dynamic resizing is something I’ve decided to relegate to later in the project. Hopefully that decision doesn’t bite me and m the arse but I haven’t a clue how I’d approach that problem right now
There is no complete spec, especially for interactions which only exist in software terminals. I've been through this myself (https://github.com/duskwuff/fvterm).
That being said:
> for example: CSI n S (Scroll Up), should that insert empty lines at the bottom (ie scrolling the content up) or scroll back through the buffer?
As a general rule, nothing interacts with scrollback. CSI S inserts empty lines at the bottom of the screen and deletes lines from the top; conversely, CSI T inserts empty lines at the top and deletes from the bottom.
Which operations should touch the scrollback is debatable. My inclination is to only append to scrollback when scrolling occurs "naturally" as the result of a newline or wrap, and neither DECSTBM nor the alternate screen are active at the time. (DECSTBM and alt-screen tend to indicate that a full-screen application is running, so saving rows to scrollback is unlikely to be meaningful.)
That being said:
> for example: CSI n S (Scroll Up), should that insert empty lines at the bottom (ie scrolling the content up) or scroll back through the buffer?
As a general rule, nothing interacts with scrollback. CSI S inserts empty lines at the bottom of the screen and deletes lines from the top; conversely, CSI T inserts empty lines at the top and deletes from the bottom.
Which operations should touch the scrollback is debatable. My inclination is to only append to scrollback when scrolling occurs "naturally" as the result of a newline or wrap, and neither DECSTBM nor the alternate screen are active at the time. (DECSTBM and alt-screen tend to indicate that a full-screen application is running, so saving rows to scrollback is unlikely to be meaningful.)
Thank you. That’s really helpful
If you want to do something that's not "a dime a dozen" (ROFL), grab a Mac, download Xcode and implement a full VK100 (aka GIGI) emulator with ReGIS graphics ...and a client-side GiGi BASIC interpreter. Note: Going from memory, IIRC.. VK100 (despite having 100 in the name) only implemented VT52 (aka ANSI) functions...not the full VT102 suite.
VK100 ESCape sequences start on Page 59 https://vt100.net/dec/vk100in2.pdf
GIGI BASIC at http://bitsavers.org/pdf/dec/terminal/gigi/AA-K335A-TK_GIGI_... (read bottom of page 1-1 carefully --think of the possibilities...you may want to add a security feature to limit that here in the post-dystopian wasteland)
VT102/400 ESCape sequences at https://manx-docs.org/collections/mds-199909/cd3/term/vt420r...
The state of the art in this area is a commercial product by a small team in Arizona at https://vandyke.com/products/securecrt/index.html
Applause for not being afraid to take on a concept that's been done (wrong) many times.
https://youtu.be/9jlQiHHMlkA
VK100 ESCape sequences start on Page 59 https://vt100.net/dec/vk100in2.pdf
GIGI BASIC at http://bitsavers.org/pdf/dec/terminal/gigi/AA-K335A-TK_GIGI_... (read bottom of page 1-1 carefully --think of the possibilities...you may want to add a security feature to limit that here in the post-dystopian wasteland)
VT102/400 ESCape sequences at https://manx-docs.org/collections/mds-199909/cd3/term/vt420r...
The state of the art in this area is a commercial product by a small team in Arizona at https://vandyke.com/products/securecrt/index.html
Applause for not being afraid to take on a concept that's been done (wrong) many times.
https://youtu.be/9jlQiHHMlkA
SecureCRT isn’t what I’d describe as state of the art. Feature rich, sure. But it’s still just a terminal emulator with a few other protocols bolted on.
What I’m building is going to be more akin to a web browser, with support for rich content from the terminal. There’s only two other projects that I know which have taken this on. One is abandoned and the other is a commercial project that doesn’t really behave like a proper terminal emulator.
What I’m building is going to be more akin to a web browser, with support for rich content from the terminal. There’s only two other projects that I know which have taken this on. One is abandoned and the other is a commercial project that doesn’t really behave like a proper terminal emulator.
I'm in the process of building a new terminal emulator. Yes, I know they're already a dime a dozen but I have plans to take this into a different direction.
Anyhow, the big problem I have is that there are literally hundreds of escape codes that you need to support even just to reach parity with xterm. And while I've been trawling through xterm's docs (eg https://www.xfree86.org/current/ctlseqs.html ) they don't really go into much detail regarding how the actual implementation should look like.
for example: CSI n S (Scroll Up), should that insert empty lines at the bottom (ie scrolling the content up) or scroll back through the buffer?
Admittedly a lot of the codes are pretty self-explanatory and I can fill in a lot of missing gaps via testing those escape codes in other terminal emulators. But having a detailed reference doc would certainly save a lot of time (and reduce the risk of error too).
To be clear, what I'm looking for is a more exhaustive list of escape codes rather than the common ones everyone already knows like SGR.
Thanks in advance :)