VT line wrapping is not quite right

[davidrg]

Based on this test, K95s line wrapping behaviour is slightly wrong for the VT420 and VT520. It might be for VT320 too, but no one has run the test for one of those and I don't have acces to one to run it myself.

Kermit 95s behaviour is the same for VT100, VT220, VT320 and the 'K95' terminal type while for real DEC terminals the behaviour changed from model to model. Lines marked with << show where K95s behaviour is wrong for one or more terminal emulations.

                     DEC 100 220 420 520 K95
wrap works           y   y   y   y   y   yes
wrap is deferred     y   y   y   y   y   yes
CPR beyond last col  n   n   n   n   n   no
CR works at margin   y   y   y   y   y   yes
BS works at margin   y   y   y   y   y   yes
TAB wraps at margin  n   n   n   n   n   no
TAB cancels wrap     y   n   y   n   n   no    <<
NL cancels wrap      y   n   y   y   y   yes   <<
NUL cancels wrap     n   n   n   n   n   no
BEL cancels wrap     n   n   n   n   n   no
RI cancels wrap      y   n   y   y   y   yes   <<
SGR cancels wrap     n   n   n   n   n   no
SM cancels wrap      n   n   n   n   n   no
CUP cancels wrap     y   n   y   y   y   yes   <<
CUF cancels wrap     y   n   y   y   y   yes   <<
EL cancels wrap      y   n   y   y   y   no    <<
ED cancels wrap      y   n   y   y   y   no    <<
DCH cancels wrap     y   n   y   y   y   no    <<
ICH cancels wrap     y   -   y   y   n   no    <<
ECH cancels wrap     y   -   y   y   y   no
CPR cancels wrap     n   n   n   n   n   no
DECSC cancels wrap   n   n   n   n   n   no
DECRC restores wrap  y   n   y   y   y   no    <<
DECRC restores AWM   n   n   n   n       yes   <<
DECRC restores !AWM  n   n   n   n       yes   <<


Columns:
DEC  architectural behaviour of DEC terminals (DEC STD-070)
100  real DEC VT100
220  real DEC VT220
420  real DEC VT420
520  real DEC VT520
K95  Kermit 95 VT100/VT220/VT320/K95 - the behaviour is the same for all

[j4james]

It's worth noting that DEC moved the auto wrap definition to the documented exceptions chapter, so it's not strictly a conformance requirement, and software is warned not to rely on the behaviour. They were well aware that the last column flag wasn't reset consistently across models.

I think it's also quite likely that "TAB cancels wrap" is a mistake in the documentation, or possibly something that they briefly considered a good idea for the VT220, but later changed their minds. This part of the documentation is from 1985, so it predates most of the later models.

[davidrg]

Yeah, K95s behaviour here is clearly good enough given its probably been like this for nearly 40 years. And given the variety of different behaviours out there I can't imagine many applications depend on it. But I'd like for its various emulation modes to match the behaviour of the real thing as closely as practical so I'll try to sort it eventually.

As for the TAB thing, apparently the test results were from real terminals so I guess TAB must really cancel wrap on a VT220. I do have a VT220 here which I might try and confirm behaviour on assuming it doesn't release the magic smoke first (its been 10-15 years since I last used it). I did check the VT510 results against my VT520 and its a match though, so I expect the results for the others are probably correct too.

One thing I've wondered about is DECSC/DECRC saving/restoring autowrap mode. I assume K95 is doing it for a reason but aside from iTerm2 nothing else that has been run through this test does it. Unless its something that only the VT320 does, I guess it must be a behaviour of one of the other VT-like terminals K95 can emulate (SNI-97801, some Wyse, etc) though who knows which one.

[j4james]

I'd like for its various emulation modes to match the behaviour of the real thing as closely as practical so I'll try to sort it eventually.

OK, that would be nice. But if you have a kind of default "kermit mode", I think it would be best to match the STD 070 docs for everything except TAB (which I believe is what Xterm does). Or another way of looking at it would be to match the VT520 for everything except maybe ICH (I'm not sure if that was a deliberate deviation or a bug).

apparently the test results were from real terminals so I guess TAB must really cancel wrap on a VT220.

Yeah, I was just saying I think that might have been the only terminal that had that behaviour. Like maybe they tried it out on the VT220, got feedback that it wasn't a good idea, and then switched back to the original behaviour for all future terminals. I know I've tested this on MAME's VT240 (and all the VT100 variants), as well as the blaze VT420 emulator, and none of them cancel wrap with a TAB control.

One thing I've wondered about is DECSC/DECRC saving/restoring autowrap mode.

I've seen nothing in the documentation to suggest that should happen, and none of the DEC terminals I've tested have done that. I also think it's unlikely to be a VT320 specific thing, just based on the DECTSR documentation here: https://vt100.net/dec/vt320/terminal_state_report

Note the byte range 10 to 21 where it saves the DECSC data. I'm assuming the undocumented byte 13 is just a copy of byte 43, which it needs to restore DECOM (I've done the equivalent map for the VT420, and it has a similar layout). If it were also restoring DECAWM, it would need to do a merge of bytes 43 and 44, which seems like an unnecessary complication (it would have made more sense include the DECAWM bit in byte 43 to start with).

[davidrg]

I'd like for its various emulation modes to match the behaviour of the real thing as closely as practical so I'll try to sort it eventually.

OK, that would be nice. But if you have a kind of default "kermit mode", I think it would be best to match the STD 070 docs for everything except TAB (which I believe is what Xterm does). Or another way of looking at it would be to match the VT520 for everything except maybe ICH (I'm not sure if that was a deliberate deviation or a bug).

For the next release K95 is gaining a "self" personality and my long-term goal is to evolve that towards a kind of "extended VT525" adopting various extensions from elsewhere if they don't conflict with anything DEC did and they make sense/are required for compatibility with modern stuff. That means the, eg, VT320 emulation doesn't need to be concerned with whether applications blindly assume 24-bit colour is supported by everything, etc - it can just do as a VT320 does.

apparently the test results were from real terminals so I guess TAB must really cancel wrap on a VT220.

Yeah, I was just saying I think that might have been the only terminal that had that behaviour. Like maybe they tried it out on the VT220, got feedback that it wasn't a good idea, and then switched back to the original behaviour for all future terminals. I know I've tested this on MAME's VT240 (and all the VT100 variants), as well as the blaze VT420 emulator, and none of them cancel wrap with a TAB control.

Yeah, it does seem like a bit of an odd choice. Bug perhaps? DEC STD 070 seems to have started out with the VT220 so maybe in this case it was documenting what the VT220 was already doing, not what it should be doing.

One thing I've wondered about is DECSC/DECRC saving/restoring autowrap mode.

I've seen nothing in the documentation to suggest that should happen, and none of the DEC terminals I've tested have done that. I also think it's unlikely to be a VT320 specific thing, just based on the DECTSR documentation here: https://vt100.net/dec/vt320/terminal_state_report

I hadn't seen this! Eventually I'm going to have to implement DECRQTSR/DECTSR and was wondering what state exactly gets saved and restored as DEC never documented it.

Note the byte range 10 to 21 where it saves the DECSC data. I'm assuming the undocumented byte 13 is just a copy of byte 43, which it needs to restore DECOM (I've done the equivalent map for the VT420, and it has a similar layout). If it were also restoring DECAWM, it would need to do a merge of bytes 43 and 44, which seems like an unnecessary complication (it would have made more sense include the DECAWM bit in byte 43 to start with).

I'm betting its just something some other non-DEC terminal did and the behaviour wasn't correctly restricted to that terminal emulation so it ends up happening for anything that supports DECSC/DECRC.