Feature Request: configurable screen buffer size

[ffays]

Description of the new feature

Provide a way to configure the screen buffer size

either

1. provide a way to configure the number of rows, and possibly columns, for the screen buffer size.
2. or provide a way to configure the maximum size of the screen buffer as number of bytes.

Note: option 1 will be backward compatible with the original cmd and prowershell consoles, and option 2 provides a better understanding of memory footprint.

Proposed technical implementation details

These settings may be defined in the configuration file Windows Terminal JSON Settings.

e,g,

(option 1)

screenBufferWidth: 160
screenBufferHeight: 100000

Where screenBufferWidth is a number of columns and screenBufferHeight a number of lines.

(option 2)

screenBufferSize 10485760

Where screenBufferSize is a number of bytes (hereby 10MB)

[zadjii-msft]

You can actually already use historySize to change the size of the scrollback, which combined with the initialRows and initialCols forms the entire size of the "screen buffer" in the terminal.

[DHowett-MSFT]

Looks like this has been answered. Let us know!

[ffays]

Thank you for your answer.

I changed the settings initialRows, initialCols and historySize, and it works as expected.

With as limitation, historySize cannot go beyond 32767 lines ... why such limitation that ages from the 16-bit computer era?

Last words: to my point of view, I believe that "historySize" term is misleading as it can be confounded with command history size...

[zadjii-msft]

So, the historySize is restricted to that because at the time of writing, both the Terminal and the vintage console share the same TextBuffer implementation. Since the vintage console needs to be restricted to SHRT_MAX lines to be able to respond to the Console API correctly, the Terminal is also locked to that size.

This is a limitation we plan on relaxing in the future - we're hoping in a future release to even add support for an "infinite scrollback" (#1410) mode (though it's unlikely to land in 1.0).