Resize locking

[lhecker]

Discussed in #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?

[The-Futurist]

OK there's a long history here:

#6895 (comment)

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]

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

[The-Futurist]

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)

pressing HOME has this effect:

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