microsoft / microsoft/terminal
Finite (but large) scrollback (not infinite)
- Dominant language
- C++
- Stars
- 105k
- Forks
- 9.6k
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 29
Description
### 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`.
```
// 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(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.
Contributor guide
Research direction
Start with the linked pull request, then inspect Terminal::Create and CreateFromSettings in src/cascadia/TerminalCore/Terminal.cpp and TextBuffer::_reserve in src/buffer/out/textBuffer.cpp, along with the declarations in textBuffer.hpp. Run the relevant terminal and buffer tests to establish current history-size limits. Done means the supported finite scrollback limit is increased consistently and covered by tests without changing infinite-scrollback behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- cli, operating-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100