Statusline (DECSASD/DECSSDT) doesn't work

[AlexKurisu]

Contour Terminal version

0.4.0-master-6df0a2f9

Installer source

something else (please specify below) AUR (contour-git)

Operating System

Archlinux

Architecture

x86-64

Other Software

vttest

Steps to reproduce

1) Run vttest 2) Go to menu 11.2.6.2 3) Run Simple Status line Test (number 1)

Expected Behavior

Text is shown in statusline

Actual Behavior

No text in statusline

Additional notes

Config file: https://gist.github.com/AlexKurisu/79f29176f4b717a4e3ac3be6c8ef28a6

[AlexKurisu]

Works fine in XTerm, btw (had to build it with --enable-status-line)

[christianparpart]

Ah interesting. Many thanks for your report (and interest)!.

We use that actively that feature. I am surprised it's not working. I'll check what vttest is doing there. Background info: I was simply implementing the spec from vt100.net. We make quite heavy use of the indicator statusline also.

[j4james]

FYI, I think the only reason XTerm passes those tests is because its status line implementation is buggy. XTerm shares the same cursor position between the status display and the main display (which I believe is incorrect). And since it always outputs \r\n in the main display before writing to the status display, that guarantees the output will always start in the first column.

However, Contour correctly tracks the status display's cursor position independently of the main display. So every time the test outputs something it ends up further and further right, until it's eventually off the end of the buffer (at least I think that's what's happening).

That said, any change to DECSSDT is meant to "initialize" the status line. The documentation doesn't say what exactly that entails, but at the very least the line should be cleared (which is something that Contour doesn't do). It's possible you should also be resetting the cursor position, and I think that might fix at least some of the tests.

However, I'm not positive that's what you should be doing. It's also possible the tests themselves are buggy. We really need to get someone to confirm the correct behavior on one of the DEC terminals.

[christianparpart]

Hey @j4james, thx for jumping in again. I have various uncertainties wrt DECSDDT/DECSASD.

The way I understand host programmable statusline (and any other SL), is, that it acts like its own display (hence the name in the mnemonic). I know it is easy to pass all tests, especially if the TE author is also authoring the test suite (like vttest) along with it.

Here, however, it actually was a bug, as introduced with the switch to QML in the frontend, some event handler (request host writable statusline to be shown) was not implemented.

Ignoring that one for a bit, what I am struggling to feel comfortable with how to deal with margins (DECSTBM/DECSLRM). In theory, you could even set these in the host programmable statusline. But that would conflict with the alternate screen (xterm invention?), where the margins are shared between primary and alternate screen.

[j4james]

Sorry, I should have mentioned I was only testing the last release version (0.3.12.262), which I think is prior to the QML switch, so the issues I'm seeing in Contour are probably different, and maybe fixed already.

Ignoring that one for a bit, what I am struggling to feel comfortable with how to deal with margins (DECSTBM/DECSLRM).

I'd be inclined to ignore margins completely. The spec does mention that origin mode is tracked separately for the status line, but there's no mention of margins being tracked separately (at least as far as I could see). The only sensible conclusion I could draw from that is that origin mode is always disabled in the status line, and margins have no effect.

DECSTBM would never make sense anyway, because there's no margin range you can possible set that would be valid. DECSLRM could potentially be set, but I'm not sure there's a whole lot of value in that. And I think it would have to be independent of the main display, otherwise the margins wouldn't apply. So I wouldn't be in a hurry to implement that without confirmation of the correct behavior.