Right now in our documentation, ESC D is defined as the VT sequence CUB. However, in the vt-100 spec, ESC D should be IND.
In fact, I'm not sure that any of what we have on ESC A, ESC B, ESC C, ESC D (source) is correct. I vaguely recall something about ANSI.SYS for those sequences, but I can't be sure.
We should investigate if those sequences are being handled correctly, and if they aren't, make sure they are fixed.
And update the documentation with whatever we find.
We may need to support the sequence that switches us between VT52<->VT100
I've been tinkering with this for a while now (mostly the VT52 side of things), and I've got to the point where I think I have a reasonable approach to splitting out those commands and adding in the rest of the VT52 functionality. What I have so far is good enough to pass at least the basic VT52 tests in Vttest.
But before I go any further, I want to check whether anyone else is planning to work on this, or if it's OK for me to continue? If you give me the go ahead, I'll try and put together a proper feature spec detailing the approach I'm taking, and you can let me know if you think I'm doing anything fundamentally wrong.
Once the VT52 stuff is out of the way, the IND command should be reasonably straightforward. But if anyone else wants to take that on in the meantime, the two issues are largely orthogonal. You can just drop the VT52 cursor movements from ActionEscDispatch, because once there's a VT52 mode in place they wouldn't be there anyway.
In VT100+, DECANM enters VT52 mode, but then in the VT52 command set there's a further ANSI mode, entered with ESC<. With VT52, up/down/right/left emit ESC A, ESC B, ESC C, ESC D. But in ANSI mode, they emit ESC [ A, ESC [ B, ESC [ C, ESC [ D. So, if you're going to implement DECANM switching to VT52 emulation, you need to by definition also implement ANSI.
(I'm only choosing up/down/right/left for example - ANSI mode changes others too)
update: never mind -- lol, I was going around in circles. ANSI = vt100+. So in effect, ESC< just exits VT52 mode.
I realise I haven't been given the go-ahead to work on this, but nobody said not to either, so I've started a draft spec outlining how I think this could be implemented (i.e. splitting the VT52 commands from the VT100 implementation). If anyone doesn't want me to continue with this, feel free to tell me to stop - I won't mind at all.
:tada:This issue was addressed in #4789, which has now been successfully released as Windows Terminal Preview v1.1.1671.0.:tada:
Handy links: