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

"CLS" does not clear the screen after "MODE" #5079

Closed
WiVi71 opened this issue Mar 22, 2020 · 5 comments
Closed

"CLS" does not clear the screen after "MODE" #5079

WiVi71 opened this issue Mar 22, 2020 · 5 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Conpty For console issues specifically related to conpty Product-Terminal The new Windows Terminal. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@WiVi71
Copy link

WiVi71 commented Mar 22, 2020

"CLS" does not clear the screen after "MODE"

  1. Enter a few commands.
  2. Type mode 10,10 then press enter
  3. Type CLS then enter.

Result :
After CLS

Also, mode con cols=n lines=n command does not work as I expected.

Edit :
The patch related to this bug seems to have occurred in this pull request.
#2729

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Mar 22, 2020
@WiVi71 WiVi71 changed the title "CLS" does not clear the screen after "MODE" "CLS" still does not clear the screen after "MODE" Mar 22, 2020
@WiVi71 WiVi71 changed the title "CLS" still does not clear the screen after "MODE" "CLS" does not clear the screen after "MODE" Mar 23, 2020
@zadjii-msft
Copy link
Member

I mean, the real problem here is that mode doesn't change the size of the Terminal. #4062 is fairly similar, but different enough. I'd bet that mode is changing the size of the conpty buffer, but that size change is never communicated to the Terminal, and that's what's making it seem like the screen hasn't cleared. The conpty's screen probably has cleared, but that's only caused the 10x10 region in the top of the Terminal buffer to get cleared.

@zadjii-msft zadjii-msft added Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Conpty For console issues specifically related to conpty Product-Terminal The new Windows Terminal. labels Mar 23, 2020
@j4james
Copy link
Collaborator

j4james commented Mar 23, 2020

Note that this is a problem for all the VT resizing sequences too. For example, you'll get the same problem resizing the screen from within a bash shell like this:

printf "\e[8;10;10t"

And if you want to make mode work, then you'll probably want to start with the VT sequences first, because ultimately that's how you're going to have to communicate this information to the Terminal.

The real issue, though, is deciding how the Terminal should deal with a resize request. When you've got multiple tabs, each potentially requesting a different size, you can't satisfy all of them at once. I've been thinking about this for a while, and there were three approaches that I considered:

  1. Ignore the size request, as we are doing now. But for this to work, it's vital that the Terminal communicate back to the host that the request has failed. If you don't do that, the Terminal and conhost get out of sync, and the renderer goes barmy..

  2. Accept the requested size as a kind of virtual window, similar to the way conhost works when the buffer width and window width are different. If the virtual window is larger than the actual window, you'll need to be able to scroll across the viewport, both horizontally and vertically (the latter being kind of tricky to differentiate from the scrollback).

  3. Accept the requested size and actually resize the whole Terminal window to fit, but only if the tab making the request is currently focused. A background tab shouldn't be able to change the size. And as with option 1, it's vital that the resulting sizes are communicated back to the different hosts for each tab.

Personally I'm in favor of option 3, but I suspect others will disagree, and it may need to be a configurable preference. It's also possible there are other better approaches that I haven't thought of.

@DHowett-MSFT
Copy link
Contributor

Ugh, we don't have an issue for handling resize in Terminal? Sorry.

@DHowett-MSFT
Copy link
Contributor

Moved discussion about resize to #5094. The pseudoconsole actually does send out window manipulation (because it needed to when you run cmd.exe inside WSL), so that part is covered.

As for the bug here: right now, unfortunately, it's by design because we do not support resizing the terminal with MODE. It's operating as expected when you clear the new smaller window.

/dup #5094

@ghost
Copy link

ghost commented Mar 24, 2020

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed Mar 24, 2020
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Mar 24, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Conpty For console issues specifically related to conpty Product-Terminal The new Windows Terminal. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

4 participants