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.

[j4james]

FYI, I've just dumped some of my notes on the DECTSR report in an issue on my vtdocs repo as a temporary measure. See j4james/vtdocs#1

When I get more time I'll try and flesh out the details on the individual fields, but hopefully it already gives you an idea of how the state is tracked when switching between the main and status displays.

[davidrg]

Awesome! That will be handy for this, and for when I get around to implementing DECTSR!

Lately I've been looking at DECLRMM, but it seems every time I go reading STD 070 or run tests on the VT520 I just find more work to do - like the status line stuff, or figuring out what the VT520 is doing with HPA on right margin.

[j4james]

Lately I've been looking at DECLRMM, but it seems every time I go reading STD 070 or run tests on the VT520 I just find more work to do

Note that the STD 070 docs are wrong in some places. The diagram on page 23 is particularly misleading. The trick is to think of the margins as a fenced off square in the middle of the screen, rather than intersecting lines. When the cursor is inside that square, it can't get out. However, when outside, you can move around wherever you want. You can also cross the fence from the outside inwards, but obviously once you're inside you can't get out again.

This covers most of cursor movement operations (CUU, CUD, CUF, CUB, CNL, CPL, BS, HT, CHT, CBT, CR, LF, FF, VT, IND, NEL, RI, DECFI, and DECBI). Operations that trigger a scroll when they hit a boundary (IND, RI, DECFI, DECBI, etc.) will only do so when inside the margin square. When outside, they just stop once they hit the edge of the screen.

Operations that shift a block of content (IL, DL, DECIC, and DECDC) will only work inside the margin square. When outside, they do nothing. Operations that shift a line of content (ICH and DCH) work both inside the square (constrained by the right margin), and also above or below it (constrained by the edge of the screen). They don't do anything when to the left or right of the square (between the top/bottom margins).

Text output follows a similar pattern of behavior. If you're inside the margin square, you wrap within that area and scroll that area. If you've above or below the square, you're only going to wrap at the edge of the screen, and wrap back to column 1. If you're right of the square, though, wrapping is the equivalent CR/LF, so you'll jump the fence and move back to the left margin before moving down (now constrained by the bottom margin because you're inside the square).

There are also a few cursor movement operations that are not constrained by the margins (CUP, HVP, HPA, HPR, VPA, and VPR) unless origin mode is set.