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

Resize locking #23801

New Issue
Open
opened 2026-01-31 08:52:58 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 08:52:58 +00:00
Owner
Copy Link

Originally created by @lhecker on GitHub (Nov 12, 2025).

Discussed in https://github.com/microsoft/terminal/discussions/19551

Originally posted by The-Futurist November 12, 2025
I'd like to request that the programmatic ability to suspend terminal window resizing be considered. Currently if an app draws something on the screen, that layout is destroyed and can become unreadable if the window size gets adjusted.

Line wrapping seems to be forced upon us, so when a window gets narrowed stuff that was laid out on the right wraps horribly.

There's no way to programmatically "undraw" and redraw stuff either to even attempt to compensate (and that compensation relies on an ability to detect resize which only seems possible some kind of timer polling and looking for height/width changes)

Perhaps new escape codes could be supported lock-resize or perhaps lock-width and unlock-width and so on, so an app could set that and then restore it when it exits so the user who wants to resize can, except when that app is running.

I'm replicating a command line interface I used to use on some minicomputers in times gone by, truly very helpful. In that setup though we used true dumb terminals so resizing the dimensions never came up (width was was often 80, but could be 132 but this was physical terminal fonts size preference not something somebody would do very often).

Back then dumb terminals often had their own specific escape sequences for whichever manufacturer made them, on the minis I worked on we had an abstraction (text file) that mapped system (ANSI standard) generic codes to terminal specific codes, so a VT100 might have a different escape sequence for position-cursor-x-y to say a Televideo V102 (actually a Televideo 955 with special memory option) or V103 and so on.

I don't care what the width/height actually are, I just need to prevent them changing while app is executing.

As a side question where can I find the definitive complete list of all supported escape sequences for the Terminal app?

Originally created by @lhecker on GitHub (Nov 12, 2025). ### Discussed in https://github.com/microsoft/terminal/discussions/19551 <div type='discussions-op-text'> <sup>Originally posted by **The-Futurist** November 12, 2025</sup> I'd like to request that the programmatic ability to suspend terminal window resizing be considered. Currently if an app draws something on the screen, that layout is destroyed and can become unreadable if the window size gets adjusted. Line wrapping seems to be forced upon us, so when a window gets narrowed stuff that was laid out on the right wraps horribly. There's no way to programmatically "undraw" and redraw stuff either to even attempt to compensate (and that compensation relies on an ability to detect resize which only seems possible some kind of timer polling and looking for height/width changes) Perhaps new escape codes could be supported `lock-resize` or perhaps `lock-width` and `unlock-width` and so on, so an app could set that and then restore it when it exits so the user who wants to resize can, except when that app is running. I'm replicating a command line interface I used to use on some minicomputers in times gone by, truly very helpful. In that setup though we used true dumb terminals so resizing the dimensions never came up (width was was often 80, but could be 132 but this was physical terminal fonts size preference not something somebody would do very often). Back then dumb terminals often had their own specific escape sequences for whichever manufacturer made them, on the minis I worked on we had an abstraction (text file) that mapped system (ANSI standard) generic codes to terminal specific codes, so a VT100 might have a different escape sequence for position-cursor-x-y to say a Televideo V102 (actually a Televideo 955 with special memory option) or V103 and so on. I don't care what the width/height actually are, I just need to prevent them changing while app is executing. As a side question where can I find the definitive complete list of _all_ supported escape sequences for the Terminal app? </div>
claunia added the Issue-FeatureNeeds-TriageNeeds-Attention labels 2026-01-31 08:52:58 +00:00
claunia commented 2026-01-31 08:52:59 +00:00
Author
Owner
Copy Link

@The-Futurist commented on GitHub (Nov 12, 2025):

OK there's a long history here:

image

https://github.com/microsoft/terminal/issues/6895#issuecomment-658997728

But a scroll bar isn't an inevitable consequence of not wrapping. Just don't display text that's past the right edge of the window, if a user wants to see it then they can widen the window.

I have zero interest in a scroll bar.

It's true, old dumb serial terminals had no scroll bar, but they also let you decide whether to wrap or not.

There are (I suppose) four ways to react when we write a character to a position past the right visible edge:

  1. Wrap: write the text underneath the current line, scrolling the text up if necessary (this is what we see today)
  2. Overlay: start overwriting the start of the current line (many dumb terminals let you choose 1. or 2. with escape sequences)
  3. Buffer: append the text to the current line in the buffer, it remains invisible unless the user widens the window.
  4. Discard: Simply discard what's written, make no changes to the buffer.

Option 3. had no meaning for dumb terminals (well a few had this where we could flip the display from narrow to wide but it wasn't used much) but today where we do allow resizing of the displayed region option 3 seems like a very helpful thing, an alterative to wrapping.

Perhaps? these could be made available as new custom escape sequences, the default would remain as it is now, but applications could select the mode that works for them.

The buffer option is perhaps programmatically less complex than wrapping, today when we wrap the number of visible lines taken up depends on the length of the written line and he char width of the windows, Terminal is doing this today. But when we simply buffer long lines the geometric programming is quite a bit simpler, every line in the buffer equates to one line on the display.

I'm sure there's a lot involved, I'm not familiar with the innards so only the team can assess the feasibility but I'd dearly like to be able to do much more with terminals/consoles under .Net than I currently can.

@The-Futurist commented on GitHub (Nov 12, 2025): OK there's a long history here: <img width="786" height="220" alt="image" src="https://github.com/user-attachments/assets/6de3a084-3a1b-4c2c-9e28-fda67abf0dbe" /> https://github.com/microsoft/terminal/issues/6895#issuecomment-658997728 But a scroll bar isn't an inevitable consequence of not wrapping. Just don't display text that's past the right edge of the window, if a user wants to see it then they can widen the window. I have zero interest in a scroll bar. It's true, old dumb serial terminals had no scroll bar, but they also let you decide whether to wrap or not. There are (I suppose) four ways to react when we write a character to a position past the right visible edge: 1. **Wrap**: write the text underneath the current line, scrolling the text up if necessary (this is what we see today) 2. **Overlay**: start overwriting the start of the current line (many dumb terminals let you choose 1. or 2. with escape sequences) 3. **Buffer**: append the text to the current line in the buffer, it remains invisible unless the user widens the window. 4. **Discard**: Simply discard what's written, make no changes to the buffer. Option 3. had no meaning for dumb terminals (well a few had this where we could flip the display from narrow to wide but it wasn't used much) but today where we do allow resizing of the displayed region option 3 seems like a very helpful thing, an alterative to wrapping. Perhaps? these could be made available as new custom escape sequences, the default would remain as it is now, but applications could select the mode that works for them. The buffer option is perhaps programmatically less complex than wrapping, today when we wrap the number of visible lines taken up depends on the length of the written line and he char width of the windows, Terminal is doing this today. But when we simply buffer long lines the geometric programming is quite a bit simpler, every line in the buffer equates to one line on the display. I'm sure there's a lot involved, I'm not familiar with the innards so only the team can assess the feasibility but I'd dearly like to be able to do much more with terminals/consoles under .Net than I currently can.
claunia commented 2026-01-31 08:52:59 +00:00
Author
Owner
Copy Link

@The-Futurist commented on GitHub (Nov 12, 2025):

@lhecker - Perhaps the title of this issue can be changed to: "Escape sequences to control line wrapping - no scroll bars expected."

@The-Futurist commented on GitHub (Nov 12, 2025): @lhecker - Perhaps the title of this issue can be changed to: "**Escape sequences to control line wrapping** - no scroll bars expected."
claunia commented 2026-01-31 08:53:00 +00:00
Author
Owner
Copy Link

@The-Futurist commented on GitHub (Nov 12, 2025):

OK I made some progress, it seems I must switch to the alternate buffer AND disable wrap, then we get it disabled.

so do this when the console app starts:

Console.Write(AnsiCodes.SELECT_ALTERNATE_BUFFER);
Console.Write(AnsiCodes.DISABLE_LINEWRAP);

and do this when we exit:

Console.Write(AnsiCodes.ENABLE_LINEWRAP);
Console.Write(AnsiCodes.SELECT_PRIMARY_BUFFER);

These are the sequences:

public static class AnsiCodes
{
    public const string ESC = "\x1b[";
    public const string DISABLE_LINEWRAP = ESC + "?7l";
    public const string ENABLE_LINEWRAP = ESC + "?7h";
    public const string SELECT_ALTERNATE_BUFFER = ESC + "?1049h";
    public const string SELECT_PRIMARY_BUFFER = ESC + "?1049l";
}

When the window narrows over existing text, that text is lost (its not being buffered). I might be able to address the lost text, the logic in fact has a Draw method that draws the entire menu, so I tried intercepting the HOME key as a test and do an auto redraw when the user presses that.

It works, so once we get this from narrowing and widening the window (not the right side text that was lost when we narrowed)

Image

pressing HOME has this effect:

Image

It need work to iron out some side effects but might well be doable.

@The-Futurist commented on GitHub (Nov 12, 2025): OK I made some progress, it seems I must switch to the alternate buffer AND disable wrap, then we get it disabled. so do this when the console app starts: ```cs Console.Write(AnsiCodes.SELECT_ALTERNATE_BUFFER); Console.Write(AnsiCodes.DISABLE_LINEWRAP); ``` and do this when we exit: ```cs Console.Write(AnsiCodes.ENABLE_LINEWRAP); Console.Write(AnsiCodes.SELECT_PRIMARY_BUFFER); ``` These are the sequences: ```cs public static class AnsiCodes { public const string ESC = "\x1b["; public const string DISABLE_LINEWRAP = ESC + "?7l"; public const string ENABLE_LINEWRAP = ESC + "?7h"; public const string SELECT_ALTERNATE_BUFFER = ESC + "?1049h"; public const string SELECT_PRIMARY_BUFFER = ESC + "?1049l"; } ``` When the window narrows over existing text, that text is lost (its not being buffered). I might be able to address the lost text, the logic in fact has a `Draw` method that draws the entire menu, so I tried intercepting the HOME key as a test and do an auto redraw when the user presses that. It works, so once we get this from narrowing and widening the window (not the right side text that was lost when we narrowed) <img width="1084" height="478" alt="Image" src="https://github.com/user-attachments/assets/8946aaf3-eacf-45a9-8609-3e93fee50ac7" /> pressing HOME has this effect: <img width="1084" height="478" alt="Image" src="https://github.com/user-attachments/assets/69986c50-350f-4da2-aaa2-dea6ded7d71b" /> It need work to iron out some side effects but might well be doable.
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-Feature Needs-Attention Needs-Triage
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#23801
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?