Terminal: Screen Buffer Size and overscrolling

[jwatt]

One irritation with terminal apps on Windows is the concept of the Screen Buffer Size. Having this be a fixed value rather than dynamically growing, and particularly the fact that the scrollable length of the window is fixed to this value, makes these Windows apps feel really archaic and clunky having had experience of macOS/Linux/etc.

Personally the apps that I build produce a lot of build output, and I want to be able to scroll back/search through it on the occassions that I need to (without having to be slowed down by the need to up a separate log file). To do that I have to set the Screen Buffer Size to something large (9999). But then most times there's an ocean of blank are below the prompt! Swipe scrolling past the end of the visual output (and prompt) and having to scroll back gets tiresome real quick...

[tobia]

Yes, coming from Ubuntu this is really annoying.

Most (all?) console apps are in either of two possible modes at any given time:

1. they are appending output uni-directionally to the bottom (by writing to stdout / stderr)
2. or they are drawing on the visible region of the console (by using curses / ncurses)

There is no instance that I'm aware of where an app writes to random places off-screen.

I think the console subsystem should keep track of the lowest (most bottom) line that has been written to since the last clear or reset call and use it as a virtual limit to the scrollable area. Otherwise it becomes really hard to scroll to the last written line, which is also the most interesting line and where all the action happens in a terminal emulator.

No other terminal emulator in the world allows scrolling below the lowest line that has been written to! It makes no sense.

[zadjii-msft]

I agree this is annoying. Unfortunately, this gets filed under one of those things that's just "inherent differences between windows and linux". Windows Consoles have always had a "buffer" that they fill, while terminals have a viewport and a scrollback that catches things that fall off.

I've been thinking about trying to implement such functionality, where we pretend that the buffer is only as big as the filled portion, (but if an app writes outside that, we'll grow to match what they've output). I don't know if that'd introduce a bunch of bugginess - I'd probably have to add a setting, which means adding a checkbox, which means making the propsheet bigger, which is asking for trouble...

Maybe in the future? I'll add it to the backlog.

[mikemaccana]

Thanks @zadjii-msft it would be so cool if you did this! People have been talking about the overscroll for ages - https://superuser.com/questions/1273370/stop-windows-command-prompt-from-scrolling-past-cursor https://github.com/Maximus5/ConEmu/issues/172 and even a new Microsoft employee (who I can't remember) wrote about it in their 'switching to Windows' guide.

[gobbedy]

I second this, my scripts spit out massive amounts of data to the console and the overscrolling makes it a nuisance to sift through. Compared to other feature requests in the backlog this ones seems like a pretty easy one too.

[mshindal]

It seems like the Windows Console knows where the prompt is, because if you produce a lot of output, scroll up, and then type something, it will jump down to where the prompt is. So if we could stop the scrolling where the prompt is, we would get the behavior we want.

[zadjii-msft]

You know, I actually made some changes in this area for the upcoming 1807 release (2Fall2CreatorsUpdate). It won't prevent you from overscrolling, but it will jump back to the spot it was before you scrolled in cmd, powershell and wsl.

It's possible in the following release (circa spring 2019) there might be more news in this area ;)

[DHowett-MSFT]

I just realized that this is a feature we shipped in 19H1 (1903):

[mikemaccana]

Brilliant. Is the default updated to avoid the overscroll? Most users probably don't want to scroll and see a bunch of blackness.

[zadjii-msft]

@mikemaccana Nope. All those features on the "Terminal" property page are all _experimental_, and they might result in unexpected (read: changed API behavior) relative to the legacy console, so they're all off by default. Users will need to opt-in to the newer functionality.

[mikemaccana]

All those features on the "Terminal" property page are all experimental

OK. What does experimental mean?

they might result in unexpected (read: changed API behavior) relative to the legacy console

Yep there's definitely a difference in behavior. But since users launching Terminal are starting a different app from those running the old console, do you think it would then be reasonable for the default behavior to be different, if the new default would be better more users?

[mikemaccana]

Oh wait are we talking about Windows Terminal or the old apps? The repo name confuses me! If we're talking about the old apps then sure don't change anything.

[zadjii-msft]

I'm talking about the "vintage" console, conhost.exe. It's a little confusing since both codebases are in the same repo, but usually you can differentiate which one a thread is talking about by examining the "Product" labels:

[mikemaccana]

Ah thanks Mike and sorry for the confusion!