Status Line Standards Conformance Improvements

[davidrg]

K95 currently implements the VT status line extension, but the implementation was done back in Kermit 95 1.1.8 (November 1996) long before DEC STD-070 was publicly available. As a result there are a few details about the current implementation that are inconsistent with the standard and potentially real terminals as well.

This issue is to eventually resolve those issues where possible. Priority is relatively low as few other terminal emulators implement the status line so no software out there actually uses it.

Everything on this list should be checked against real hardware before making changes as there is the possibility some of the DEC VT terminals being emulated also don't follow the standard. In those cases we should do as real hardware does.

The following things are set out in (14.2.3)

• Toggling DECSCNM should affect both thet terminal display and status line when the status line is host-writable
• Toggling DECCOLM should also clear the status line
• DECTCEM should be tracked separately for the VTERM and VSTATUS - its currently settable for VTERM only. Easy fix.

Additionally,

• On DECSASD, K95 effectively does a DECSC first blowing away any existing saved cursor before switching. The spec doesn't say this is the wrong behaviour, but it does imply it. Need to check on real hardware. Easy fix if needed.

[j4james]

On DECSASD, K95 effectively does a DECSC first blowing away any existing saved cursor before switching. The spec doesn't say this is the wrong behaviour, but it does imply it. Need to check on real hardware. Easy fix if needed.

This is explained in section 14.2.2 of the Status Display Extension docs:

The following information is maintained separately for the Host Writable Status Line and the Main Display:

• Active Position
• Current Graphic Rendition (and other character attribute values)
• Origin Mode
• the currently designated G0, G1, G2, and G3 sets
• the currently invoked GL and GR sets
• the single shift (SS2, SS3) states
• the Auto-Wrap flag
• Cursor Save Buffer (DECSC and DECRC)

I think there are possibly a couple of other modes or flags that are saved as well. This was one of the things I noticed when testing DECTSR, because you could see all these chunks of data being moved around in its serialisation of the terminal memory.

[davidrg]

On my VT520 toggling DECOM while on the status line doesn't affect the state of DECOM on the terminal screen so state is indeed tracked separately. But with only one line DECSTBM isn't useful, and the VT520 doesn't seem to implement DECLRMM on the status line either (turning on DECLRMM and setting margins seems to do nothing) so I'm not sure what use enabling DECOM on the status line serves - perhaps future proofing for if something ever had a multi-line host-writable status display?

[j4james]

I suspect it may just be because it shares the same structure as the Save Cursor Buffer. There's a block of variables that get saved in DECSC, and an additional two copies of that block are saved when switching to the status line (i.e. it makes a copy of the main state as well as the DECSC state).

I really need to put together a document of some sort with my notes on DECTSR, because when you can see the way the memory is laid out it starts to make a lot more sense I think.

[j4james]

I've just been checking my DECTSR notes, and the other modes that are maintained separately for the status line are DECTCEM and DECNRCM. DECTCEM is actually documented in the next section on page 14-9. And DECNRCM kind of make sense if you think of it as being necessary to preserve the character set designations.

I should also note these modes (DECAWM, DECTCEM, and DECNRCM) and all stored in the same byte on the VT420 when saving the state for the status line, despite the fact that they're sourced from four separate bytes in the main memory. I had previously thought it unlikely they'd be merging bits like that, but I was wrong in that assumption.