Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CUU and CUD commands should be constrained by the scrolling margins #170

Closed
j4james opened this issue May 5, 2018 · 2 comments
Closed
Labels
Product-Conhost For issues in the Console codebase Resolution-Fix-Available It's available in an Insiders build or a release
Milestone

Comments

@j4james
Copy link
Collaborator

j4james commented May 5, 2018

  • Your Windows build number:

Microsoft Windows [Version 10.0.16299.371]

  • What you're doing and what's happening:

I'm setting the top and bottom scrolling margins with the DECSTBM escape sequence, then using the CUU and CUD sequences to move about within that range. According to the VT100 documentation for CUU: "If an attempt is made to move the cursor above the top margin, the cursor stops at the top margin." Similarly for the CUD command: "If an attempt is made to move the cursor below the bottom margin, the cursor stops at the bottom margin.

But that's not the behaviour I'm seeing in the Windows console. In the test case below, I've set the top margin to 8, the bottom margin to 16. Then starting from the centre of that range, I move down 99 lines and output some text to mark the bottom of the range, then up 99 lines to mark the top of the range.

printf "\ec\e[8;16r\e[12H\e[99BBOTTOM\r\e[99ATOP\n"

If everything is working correctly, I'd expect the TOP and BOTTOM markers to be on line 8 and 16 respectively, but in the Windows console they appear at the very top and bottom of the screen. The screenshots below compares the output on XTerm, Konsole, Gnome Terminal, and the Windows console (left to right).

image

  • What's wrong / what should be happening instead:

The vertical cursor movement commands CUU and CUD should not be able to move outside the scrolling margins - they should be constrained within those boundaries, the same way the various Linux terminal emulators behave.

@j4james
Copy link
Collaborator Author

j4james commented May 5, 2018

I should probably also mention that the VT52 movement commands (ESC A and ESC B) have the same problem. They're a little more difficult to test, since you can only move one line at a time, but the script below demonstrates the issue in a similar way.

#! /usr/bin/env bash
printf "\ec\e[8;16r\e[12H\e[?2l"
for i in {1..99}; do printf "\eB"; done
printf "BOTTOM\r"
for i in {1..99}; do printf "\eA"; done
printf "TOP\n\e<"

Note the \e[?2l sequence is necessary to enable VT52 mode on most terminals, and the \e< sequence is to switch back to VT100 mode.

The results are much the same as before, except that Gnome Terminal doesn't support the VT52 commands at all.

@zadjii-msft zadjii-msft added Work-Item It's being tracked by an actual work item internally. (to be removed soon) console labels May 7, 2018
@zadjii-msft zadjii-msft added this to the RS5 milestone May 7, 2018
@zadjii-msft zadjii-msft added Product-Conhost For issues in the Console codebase and removed console labels May 21, 2018
@zadjii-msft zadjii-msft added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed Work-Item It's being tracked by an actual work item internally. (to be removed soon) labels Jul 6, 2018
@zadjii-msft zadjii-msft added Resolution-Fix-Available It's available in an Insiders build or a release and removed Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. labels Oct 25, 2018
@zadjii-msft
Copy link
Member

Looks like it's fixed in the 2018 October Update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Product-Conhost For issues in the Console codebase Resolution-Fix-Available It's available in an Insiders build or a release
Projects
None yet
Development

No branches or pull requests

2 participants