Support for VT100 DECOM Orgin Mode

[j4james]

Windows build number: [Version 10.0.16299.248]

If you telnet to mapscii.me, it starts off looking OK (aside from possible unicode issues if you don't have a good enough font). However, if you try to zoom in (pressing the A key), you'll notice that the updated view scrolls into place instead of refreshing smoothly, and the first line of the display will appear to be incorrect.

The reason this is happening is because they're setting the DECOM origin mode at the start of every screen refresh (\033[?6h), and one of the side effects of that sequence is that the cursor is supposed to be reset to the home position. Since Windows doesn't support that sequence, the cursor is in the wrong place when the new screen is output.

The end result is that half of the first line for the updated view is appended to the end of the previous view, and ultimately won't be seen. And the rest of the page then slowly scrolls into position as it's output instead of smoothly overwriting the previous content.

I'm not sure if the screen margins are ever set, so that functionality may not be necessary for mapscii to work correctly, but it definitely seems to be relying on the mode change resetting the cursor to the home position, so it would be good if the Windows console could support that.

[oising]

Did this get fixed? mapscii.me is down, so I can't verify.

[zadjii-msft]

Nope, not yet. Still on the backlog.

[oising]

is DECOM supported at all, or is it just the cursor reset that isn't working?

[zadjii-msft]

I don't believe DECOM is supported at all.

[oising]

Hmm, I'll tell you why I'm curious. I've got a simple multiplexer I'm trying to build, and I'm setting a scroll region (DECSTBM) to isolate the bottom line for a status bar, a la screen/tmux (using conpty.) I find that the text in the status bar gets corrupted/cleared at some point, like the cursor is ending up outside the scroll region in the bottom margin. If I force a long dir -R from the root, eventually the "status" bar gets wiped. I'll try to get a better repro and open a new issue. I was wondering if using DECOM was the fix.

[zadjii-msft]

God bless you for trying to do this - I've had plans to try and create one for a while now, but there are some other things that are higher priority at the moment.

I doubt that DECOM would be the fix, considering that tmux is able to function perfectly fine w/o it. Presumably the bug would repro without conpty involved - if you can get me a set of VT sequences that repro the behavior, I'll be happy to take a look. (though preferably in a separate issue :P)

[oising]

The first thing I tried was seeing if tmux/screen had similar issues, but to be honest, they have such different architectures with what I've got that I couldn't be sure. I'll try without conpty to see if there's an issue.

[oising]

@zadjii-msft -- this is what's currently bothering me most: #394

[miniksa]

Related to #94?

[DHowett-MSFT]

Marking this one Help-Wanted! This could be a nice pickup task.

DECOM origin mode is described here:

When DECOM is set, the home cursor position is at the upper-left corner of the screen, within the margins. The starting point for line numbers depends on the current top margin setting. The cursor cannot move outside of the margins.

When DECOM is reset, the home cursor position is at the upper-left corner of the screen. The starting point for line numbers is independent of the margins. The cursor can move outside of the margins.

[j4james]

I've spent some time looking into this, and I think it's something I can handle if nobody else is working on it.

My approach would be to add two new booleans in the AdaptDispatch class - one to track the current origin mode, and a second to track the origin mode associated with the saved cursor position.

When the origin mode is relative, there would then need to be adjustments to the line number in the CursorPosition method, the VerticalLinePositionAbsolute method, and the _CursorPositionReport method. The HardReset and SoftReset methods would also require some additions to reset the origin mode to absolute positioning. Oh and the CursorSavePosition and CursorRestorePosition methods would need to save the origin associated with the cursor, as mentioned above.

I'm still investigating some of the edge cases, but I think that's the gist of it. However, I should point out that I'll only be able to get back to this again next weekend, in case someone else is keen to take it on before then.

[zadjii-msft]

That certainly seems like the way I'd do it. I doubt that anyone else is going to take a stab at it before that, so I'll just put you on it :P

[DHowett-MSFT]

Good news! This was released for the in-box console with insider build 18945!

[ghost]

🎉This issue was addressed in #1331, which has now been successfully released as Windows Terminal Preview v0.3.2142.0.:tada:

Handy links:

• Release Notes
• Store Download