starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Closed
opened 2026-01-31 00:54:56 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 00:54:56 +00:00
Owner
Copy Link

Originally created by @WiVi71 on GitHub (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.
https://github.com/microsoft/terminal/pull/2729

Originally created by @WiVi71 on GitHub (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](https://user-images.githubusercontent.com/59140461/77266840-075b7900-6ce4-11ea-9856-7ad30c3bb2a1.PNG) 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. https://github.com/microsoft/terminal/pull/2729
claunia commented 2026-01-31 00:54:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 23, 2020):

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 commented on GitHub (Mar 23, 2020): 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.
claunia commented 2026-01-31 00:54:58 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (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.

@j4james commented on GitHub (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.
claunia commented 2026-01-31 00:54:58 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 24, 2020):

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

@DHowett-MSFT commented on GitHub (Mar 24, 2020): Ugh, we don't have an issue for handling resize in Terminal? Sorry.
claunia commented 2026-01-31 00:54:58 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 24, 2020):

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

@DHowett-MSFT commented on GitHub (Mar 24, 2020): 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
claunia commented 2026-01-31 00:54:58 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (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 commented on GitHub (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!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Priority-2 Product-Conpty Product-Terminal Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#7099
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?