Resize locking

[The-Futurist]

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?

[DHowett]

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

You may be happy to learn that the alternate screen buffer (which is recommended for use by applications that want to control the entire screen buffer!) does not wrap in pretty much any terminal emulator that supports wrapping.

It does, however, suppress scrollback. That may be a deal breaker!

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

I wish we had this documented in a nice and easily-consumable format. We have a source generator that tries to divine what's supported based on some code comments, but there is nothing definitive and nobody has taken the time to profile it. Yet.

On a lark, I ran that tool to see what it produced. I can already tell you that it's wrong (it didn't detect DECOM, LNM, DSR (CPR), many of the ID functions, etc. Still perhaps academically interesting.

sequences.html

[The-Futurist]

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

You may be happy to learn that the alternate screen buffer (which is recommended for use by applications that want to control the entire screen buffer!) does not wrap in pretty much any terminal emulator that supports wrapping.

It does, however, suppress scrollback. That may be a deal breaker!

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

I wish we had this documented in a nice and easily-consumable format. We have a source generator that tries to divine what's supported based on some code comments, but there is nothing definitive and nobody has taken the time to profile it. Yet.

On a lark, I ran that tool to see what it produced. I can already tell you that it's wrong (it didn't detect DECOM, LNM, DSR (CPR), many of the ID functions, etc. Still perhaps academically interesting.

sequences.html

Thanks.

I'm not familiar with the alternate screen buffer, I'll look this up. The pain point is that we draw an interactive, navigable menu to the user, all done in text. They can tab around input fields, they can enter text into text boxes, we support insert/overlay text insertion and so on. The user either cancels the command or submits it.

During that time (when menu is editable and navigable) if we resize the width smaller the text wraps totally screwing up the appearance of the menu. When the user runs the command we dynamically build the menu and we auto fit it to the current width of the window.

If the cursor is at the bottom of the window when they invoke the command we scroll up as many lines as we need to in order for the menu to fit.

This stems from earlier interactive command menu work done on dumb terminals in the 1980s - being physical one could not shrink the width and get text wrapping.

I could get this operational if the wrapping was stopped, if the narrow the window we don't care, it will simply hide the leftmost part of the menu, if they widen the window we don't care there's just be empty space to the left.

So that's the core pain here I really want this to be platform agnostic too, so Win32 trickery!

Also I'm still a little confused about the relationship between the old Console app and Terminal. I gather Terminal "hosts" that old console in some way, so I'm not sure if I'm struggling with Console app limitations or Terminal limitations...

[The-Futurist]

Here's how the beta looks now on a console (no Terminal) session on Windows, under VS debug, the command is invoked and draws the menu to fit the width:

If we narrow the window a character or two:

If we widen it a bit:

Why that grey area spreads that way is not yet understood, it might be a bug or could be some side effect of resizing, some odd undocumented behavior (I suspect its because the last char written was in that grey background color so possibly not hard to address, but it seems the console is padding with spaces and the background color makes them visible) but the wrapping is the major concern:

If the window was narrowed a lot:

Its just terribly ugly, fixing the width (temporarily while the menu is active) would solve these issues in one hit.

[DHowett]

Why that grey area spreads that way is not yet understood,

Oh, that was a bug (#32) which we fixed in 2022 with #12637. Getting releases out through Windows, however, means it takes much longer than it should for fixes to get out to the console. :)

[DHowett]

Wait, this should have come out in Windows 24H2...

[The-Futurist]

@DHowett - The alternate buffer is promising, the wrap has gone but it erases text so that when we widen it again the text is lost.

narrow it:

rewiden it

Conceivably we could redraw the fields but that means running a thread/timer to detect window with changes, not impossible but again a real drag.

[lhecker]

Why don't you use one of the many popular TUI drawing applications to make it properly interactive? Depending on what programming language you're using, those libraries can be extremely easy to use.

[The-Futurist]

Hi, I looked briefly at some of them, I got the impression they are primarily aimed at output, nicely formatted and presented text output. Not clear that they are a good fit for this stuff. This was started a few years back but frozen for various reasons. I'm looking to resume it but the nature of the console/terminal is challenging.

[lhecker]

Oh, I was viewing this in an outdated tab and didn't see the lengthy discussion. Because of this I opened #19552 to discuss this as a feature suggestion.

[The-Futurist]

I just discovered that we can disable line wrap easily by using an escape sequence!

[The-Futurist]

I'm losing my mind, a few minutes it seemed to work, now a second debug test and it doesn't this is hellish the whole console stuff is hellish.

Here's what Copilot told me:

I began this work a couple years back and it began by doing a thorough investigation of what the console could and could not do, its precise behavior when writing, scrolling and so on was studied. But now we have Terminal and that differs and in ways that are not totally clear. I (think I) knew about the wrap issue and had an outline way to address it but that was some time ago and Terminal wasn't considered.

[o-sdn-o]

@The-Futurist

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.

This is already implemented in vtm and can be used directly in Windows Terminal.

Sequence	Description
ESC [ 12 : n p	Set text autowrap mode, default is On: n = 1 On n = 2 Off

(list of the vtm's private control sequences)

You can play around with this functionality and decide whether it's worth it.

• To get a non-wrapped cmd.exe console inside Windows Terminal:

  vtm.exe --tui --config "<config/terminal/scrollback/wrap=0/>" --run cmd.exe
  

  or

  vtm.exe -t -c "<config/terminal/scrollback/wrap=0/>" -r cmd.exe
  

• You can switch the line wrapping mode on fly (inside the powershell vtm -t -r pwsh.exe console):

  Write-Output "Resize the terminal window manually.`n`e[12:2p[+++++++++++++++++++++++++++ Long unwrapped line +++++++++++++++++++++++++]`n`e[12:1p[--------------------------- Long wrapped line ---------------------------]`n`n"
  

The buffer option is perhaps programmatically less complex than wrapping

Supporting unwrapped lines of text in the terminal is much more difficult than wrapping lines, as the entire functionality of the terminal and terminal applications is oriented toward wrapping lines, making it nearly impossible to make this compatible with the terminal world.

[o-sdn-o]

What is VTM?

In this case, vtm acts as an intermediary between Windows Terminal and your application. It reformats the output received from your application and displays the result in Windows Terminal. It handles unwrapped lines of text that extend beyond the terminal viewport so that this text isn't lost when the terminal window is resized.

What I am building is a small (but sophisticated) API that can dynamically draw and allow navigation and text input to a "form" like some of the images I posted.
But it seems that it is already supported using the alternate buffer and those enable/disable sequences?

In your case, you don't need to worry about text wrapping at all. And vtm isn't needed here. You just need to track terminal window resize events and redraw your application's interface based on the new window size so everything fits.

Common practice:

1. At startup, the application switches to an alternative mode to avoid interference with the scrollback buffer when the terminal window is resized.
2. Requests the current terminal window size.
3. Draws its interface in the terminal window.
4. Waits for user input or a terminal window resize.
5. When the terminal window is resized, proceeds to step 2.
6. When the application exits, switches to normal mode.

The only thorny issue here is the lack of a cross-platform approach for tracking terminal window resize events. Windows has its own approach, and Unix-like applications have their own.

[The-Futurist]

What is VTM?

In this case, vtm acts as an intermediary between Windows Terminal and your application. It reformats the output received from your application and displays the result in Windows Terminal. It handles unwrapped lines of text that extend beyond the terminal viewport so that this text isn't lost when the terminal window is resized.

What I am building is a small (but sophisticated) API that can dynamically draw and allow navigation and text input to a "form" like some of the images I posted.
But it seems that it is already supported using the alternate buffer and those enable/disable sequences?

In your case, you don't need to worry about text wrapping at all. And vtm isn't needed here. You just need to track terminal window resize events and redraw your application's interface based on the new window size so everything fits.

Common practice:

1. At startup, the application switches to an alternative mode to avoid interference with the scrollback buffer when the terminal window is resized.
2. Requests the current terminal window size.
3. Draws its interface in the terminal window.
4. Waits for user input or a terminal window resize.
5. When the terminal window is resized, proceeds to step 2.
6. When the application exits, switches to normal mode.

The only thorny issue here is the lack of a cross-platform approach for tracking terminal window resize events. Windows has its own approach, and Unix-like applications have their own.

Yes, that's exactly what I did yesterday, once I confirmed that wrapping can be disabled, redraw upon resize. You're right too in that I don't now need to really worry about wrapping at all, I can just begin by clearing the screen, because this is the alternate buffer the only thing cleared is the "old" form.

[The-Futurist]

I wonder if I can actually use the ordinary buffer now. That is do not do a clear screen at the start of DrawForm but instead simply position to col zero of each line in the displayed form and do a clear-to-end-of-line? is there such an escape sequence?

Also when the screen shrinks and lines wrap. then line X begins at cursor row X, but line X+1 now (visually) will appear at cursor row X+1 - is that true?

[The-Futurist]

OK I answered my own question, line erase doesn't do what I'd hoped.

If we have this:

A single line (with new line at the end) drawn at 0,0.

Now we shrink it and it wraps:

Now go back to 0,0 and write ERASE_IN_LINE_2 = ESC + "2K"

So it erase the windows line, not the buffered line.

[o-sdn-o]

I wonder if I can actually use the ordinary buffer now.

If the application remains in normal mode, then during random window resizing, unexpected things will very likely occur, such as overlapping lines of text appearing out of nowhere, random movements of the text cursor, etc. I know of only one terminal that correctly reflows scrollback during resizing. By correct reflow, I mean the terminal should always clearly display the text line layout for any window size (even up to size of 1x1). Regardless of the number of consecutive window resizes, all text and the text cursor must remain strictly in place and not move anywhere - you decrease the window size, then increase it - everything should be as before - exactly the same. So, to avoid unexpected side effects during resizing, applications have to switch to alternate mode.

[The-Futurist]

Is it recommended these days to not use stuff like Console.ForegroundColor to get/set that property and instead use ANSI sequences?

[DHowett]

Hmm. As of the new console hosting infrastructure (available in Terminal 1.22 and WezTerm so far, but more are coming), anything passed to Console.ForegroundColor's setter is transformed directly into VT sequences. It's not going to let you use any of the non-Windows-Console colors such as "default", anything in the xterm color palette (indices 17-255) or anything 24-bit, but it will still work in a pinch.

[DHowett]

(I can't find your message, so I suspect you figured it out! As the engineering manager for the entire console subsystem on Windows, I'm sorry about the tribal knowledge and how difficult it's been.)

[The-Futurist]

Thanks @DHowett , after posting a whine I saw a typo in my escape sequence. I got it now, I'm planning rip out as many Console API calls as I can (even if they do get translated to ESC codes) and this looks pretty good now, I think I can soon resume work on more basic functionality and bugs soon, now that the wrap nightmare is over.

Incidentally, if Windows Terminal alternate buffer works without wrap, why can't nowrap become an option for the primary buffer mode? Surely code reuse in some way is potentially doable?

As for colors. I settled upon this ESC sequence, easily sufficient for my needs:

public static byte ForegroundColor
{
    set
    {
        Console.Write($"{ESC}[38;5;{value}m");
        forgeroundColor = value;
    }
    get
    {
        return forgeroundColor;
    }
}

public static byte BackgroundColor
{
    set
    {
        Console.Write($"{ESC}[48;5;{value}m");
        backgroundColor = value;
    }
    get
    {
        return backgroundColor;
    }
}

That lets me do this:

See here.

[The-Futurist]

When I start my app, before any IO is done, right after entering Main, this is what I see:

When I start the app to use Conhost, I see:

That blue background is defaulting (somehow, I don't care) but in the app Console.BackgroundColor is 0 which means black. So how can I get the current background color at app start up when running under Terminal?

I can force the background color by the app of course (not caring what the terminal default is), which is no huge deal but when the app ends and we switch back to the primary buffer the new background color remains, messing up the user's main session color.

I tried doing this when the app ends but it didn't do anything:

[The-Futurist]

OK I think I have success with all this now, here's how a test example renders:

Resize works fine. As for background I understand now, we can set background, write chars then use the ANSI reset sequence, no need to know what to reset it to!

In this current beta the caller can specify title color, editbox background color and field name color and editbox text color.

Thanks to you all for assisting with this stuff, it behaves very well under terminal or conhost now.