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

Finite (but large) scrollback (not infinite) #23522

New Issue
Open
opened 2026-01-31 08:44:41 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 08:44:41 +00:00
Owner
Copy Link

Originally created by @yumeyao on GitHub (Aug 13, 2025).

Description of the new feature

Currently the maximum historysize is 32767, which is really a small number and quite insufficient. There is also another feature request #1410 to set the line limit to infinity.

This is not a duplicate of that issue because increasing the limit only requires a small code change to just increase the buffer limit without losing performance, whereas infinity requires more complicated code changes to make the buffer able to resize/extend (maybe using a rope).

I'm saying without losing performance because #15524 was merged, now it's using virtual memory allocations so that the "real" memory use increases only when you really use that much buffer.

And the code change is quite small, just change these Utils::ClampToShortMax and gsl::narrow<uint16_t>.

// src/cascadia/TerminalCore/Terminal.cpp:
// void Terminal::Create(til::size viewportSize, til::CoordType scrollbackLines, Renderer& renderer)
    const til::size bufferSize{ viewportSize.width,
                                Utils::ClampToShortMax(viewportSize.height + scrollbackLines, 1) };

// void Terminal::CreateFromSettings(ICoreSettings settings, Renderer& renderer)
    Create(viewportSize, Utils::ClampToShortMax(settings.HistorySize(), 0), renderer);

// src/buffer/out/textBuffer.cpp
// void TextBuffer::_reserve(til::size screenBufferSize, const TextAttribute& defaultAttributes)
    const auto h = gsl::narrow<uint16_t>(screenBufferSize.height);

// src/buffer/out/textBuffer.hpp
// class TextBuffer final
    uint16_t _height = 0;

Currently these code effectively limits the max buffer size(height) to 32767, we can just increase the limit here.

Proposed technical implementation details

  • We can just change the hard limit in TextBuffer to int32_t (2^31-1) because CoordType is currently int32_t and it is large enough.
    • We can change the code above in textBuffer.hpp|cpp to use CoordType or int32_t
    • We can also change type of _width for alignment. Also int16_t is slow on modern x86(ia32/x64)/ARM64 CPUs (although it's not the key point here but nice to have) 
      uint16_t _width = 0;
uint16_t _height = 0;
  • Relax the hard limit when creating the Terminal class
    • maybe clamps to INT_MAX
  • Better to have another layer of soft limit in settings
    • maybe we don't need INT_MAX, we can really set it to something like 999'999'999 or 100'000'000. The reason here is because I think many people (like me) hates the 32767 limit (but not aware there is a hard limit inside) and fill tons of 9s in the settings. This helps reduce the virtual allocation size because virtual address space is still a resource and wasting it too much may have a side-effect that limits down the maximum tabs a user can open.
    • After the change we can let users know there was a hard limit and now it's increased, please revise your settings of this value blah blah, so that if a user previously really set it to more than 10 9s and clamps to INT_MAX, the user can set it to a more reasonable value to avoid potential issues like stated above.
Originally created by @yumeyao on GitHub (Aug 13, 2025). ### Description of the new feature Currently the maximum historysize is `32767`, which is really a small number and quite insufficient. There is also another feature request #1410 to set the line limit to infinity. **This is not a duplicate of that issue** because increasing the limit only requires a small code change to just increase the buffer limit without losing performance, whereas *infinity* requires more complicated code changes to make the buffer able to resize/extend (maybe using a rope). I'm saying without losing performance because #15524 was merged, now it's using virtual memory allocations so that the "real" memory use increases only when you really use that much buffer. And the code change is quite small, just change these `Utils::ClampToShortMax` and `gsl::narrow<uint16_t>`. ``` // src/cascadia/TerminalCore/Terminal.cpp: // void Terminal::Create(til::size viewportSize, til::CoordType scrollbackLines, Renderer& renderer) const til::size bufferSize{ viewportSize.width, Utils::ClampToShortMax(viewportSize.height + scrollbackLines, 1) }; // void Terminal::CreateFromSettings(ICoreSettings settings, Renderer& renderer) Create(viewportSize, Utils::ClampToShortMax(settings.HistorySize(), 0), renderer); // src/buffer/out/textBuffer.cpp // void TextBuffer::_reserve(til::size screenBufferSize, const TextAttribute& defaultAttributes) const auto h = gsl::narrow<uint16_t>(screenBufferSize.height); // src/buffer/out/textBuffer.hpp // class TextBuffer final uint16_t _height = 0; ``` Currently these code effectively limits the max buffer size(height) to 32767, we can just increase the limit here. ### Proposed technical implementation details - We can just change the hard limit in `TextBuffer` to `int32_t (2^31-1)` because `CoordType` is currently `int32_t` and it is large enough. - We can change the code above in `textBuffer.hpp|cpp` to use `CoordType` or `int32_t` - **We can also change type of `_width`** for alignment. Also `int16_t` is slow on modern x86(ia32/x64)/ARM64 CPUs (although it's not the key point here but nice to have) ``` uint16_t _width = 0; uint16_t _height = 0; ``` - Relax the hard limit when creating the `Terminal` class - maybe clamps to `INT_MAX` - Better to have another layer of soft limit in `settings` - maybe we don't need `INT_MAX,` we can really set it to something like `999'999'999` or `100'000'000`. The reason here is because I think many people (like me) hates the 32767 limit (but not aware there is a hard limit inside) and fill tons of `9`s in the settings. This helps reduce the virtual allocation size because virtual address space is still a resource and wasting it too much may have a side-effect that limits down the maximum tabs a user can open. - After the change we can let users know there was a hard limit and now it's increased, please revise your settings of this value blah blah, so that if a user previously really set it to more than 10 `9`s and clamps to `INT_MAX`, the user can set it to a more reasonable value to avoid potential issues like stated above.
claunia added the Area-OutputIssue-TaskProduct-TerminalPriority-2 labels 2026-01-31 08:44:42 +00:00
claunia commented 2026-01-31 08:44:42 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 13, 2025):

A "small code change" is it? 😏 See #18290.

@lhecker commented on GitHub (Aug 13, 2025): A "small code change" is it? 😏 See #18290.
claunia commented 2026-01-31 08:44:43 +00:00
Author
Owner
Copy Link

@yumeyao commented on GitHub (Aug 14, 2025):

Edited to:

  • Add a missing part to change in TextBuffer class definition.
  • Add a proposal with the further ideas for improvement (the soft limit in settings)

@lhecker
ah yes, I'm missing the UI parts.

@yumeyao commented on GitHub (Aug 14, 2025): Edited to: - Add a missing part to change in `TextBuffer` class definition. - Add a proposal with the further ideas for improvement (the soft limit in settings) @lhecker ah yes, I'm missing the UI parts.
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 Area-Output Issue-Task Priority-2 Product-Terminal
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#23522
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?