DEC private 47/1047 not supported (alt buffer)

[egmontkob]

Environment

Windows build number: Win32NT 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0

Steps to reproduce

printf '\e[?47h'

or the same with 1047, and l.

Expected behavior

DEC private mode controls 47 and 1047 should switch to/from the alternate screen, just as 1049 already does in WT. Except that these shouldn't save and restore the cursor and clear the alternate screen.

Current terminfo uses 1049 for TERM=xterm-256color and friends, but older systems or apps not relying on terminfo might still emit the older 47 or 1047.

(While at it, please check 1048 too, I haven't checked that one.)

Actual behavior

Nothing happens on these.

[j4james]

Do you know of any applications that actually depend on these commands though? It's just that XTerm has a boatload of proprietary sequences, several of which are duplicates, or backwards compatibility hacks of questionable value. If it were up to me, I wouldn't want to bloat the code with cruft like this unless it was genuinely needed.

And in case anyone does want to implement this, it's also worth mentioning that the differences between 1049, 1047 and 47 are a little more subtle than what you've described. 1049 clears the screen on the way in, 1047 clears on the way out, and 47 doesn't clear the screen at all.

[egmontkob]

Thanks a lot for this precious feedback!

Do you know of any applications that actually depend on these commands though?

I don't have any concrete example.

I had the impression that changing 47 to 1049 in terminfo (for TERM=xterm) was a relatively new thing. Well, it happened in ncurses-5.5, released 14 years ago. So my impression wasn't quite correct :D

That being said, there might be applications that have the old sequence hardcoded, I don't know.

1047 clears on the way out

Indeed, I didn't remember this detail.

In fact, pushing it one step further (I'm looking at VTE's source, although I should probably check xterm):

1049 clears on the way in, even if already on the alternate screen and this is reinforced by another 1049h (and this is xterm's behavior, too). [*]

1047 clears on the way out only if actually leaving the alternate screen, not if the normal screen is reinforced by another 1047l.

Some of these only make a difference if you're using a mixture of these numbers, e.g. 47+1047 or 49+1049. As long as you're on the normal screen, the alternate screen's contents is a Schrödinger's cat.

([*] I find this a questionable design. Shouldn't setting a boolean to its previous value guaranteed to be a no-op? Nevermind.)

If it were up to me, I wouldn't want to bloat the code with cruft like this unless it was genuinely needed.

On one hand, it should be fairly easy to implement (just a few lines of wiring; the actual features are already implemented). On the other hand, as you pointed out, we're not sure if anyone still uses these.

Let's leave this call to the Microsoft guys :)

[j4james]

([*] I find this a questionable design. Shouldn't setting a boolean to its previous value guaranteed to be a no-op? Nevermind.)

Absolutely. They're quite clearly not modes. And once you start looking at all the edge cases, it becomes obvious how ridiculously underspecified they are. I'd be surprised to find any two terminals that implemented them identically. Even XTerm looks buggy to me in some respects, but because there's no actual specification, their implementation is technically the standard. At least until it gets an update one day, and then suddenly the standard has changed. Sorry for the rant, but I really loath these commands.

Let's leave this call to the Microsoft guys :)

Yeah. I'm happy to accept whatever they decide.

[DHowett-MSFT]

Is it generally possible to pair the -49 series with the -47 series? Can you push 1049h and then 47l? If it's just changing the entry/exit params on the alt buffer, it's probably not a terrifically difficult problem for us to solve.

[egmontkob]

There's no "-49 series" since plain 49 is not part of this game.

47/1047/1049 all toggle the same altscreen property, not different ones. So yup, e.g. 1049h enters the alt screen and then 47l leaves it. Someone has to be truly out of their minds to do this, though. :) Similarly, I think (but this is to be double checked) that DECSC/DECRC, SCOSC/SCORC, 1048 and 1049 all use the same single slot for the saved cursor.

[j4james]

I'm just working on a PR for the DECSC/DECRC stuff at the moment and have been testing the interaction with 1049 (and a little bit of 1047/47 too). There are a number of issues with our 1049 implementation that still need fixing, and I think we should be concentrating on that first. But the way we've implemented the alt buffer is going to make it difficult to exactly match XTerm.

As for 1047/47, we can't simply implement it as 1049 without clearing the screen (ignoring the cursor issues for the moment), because we create a new alt buffer every time, so the screen is automatically cleared. Not that any of this is unsolvable - it's just not necessarily that straightforward for us as it might be for other implementations.

I should also mention I haven't found any terminals that exactly match the XTerm behaviour for these commands, so it's probably not that big a deal. Although to be fair, I don't test with the latest versions of everything, so maybe I'm seeing issues that have already been fixed.