Hi, another testing the waters proposal; this one is more ambitious code-wise.

Basically, I like having a large buffer for search, but kitty just eats way too much memory for scrollback (for reference as of today, starting an empty kitty with 64k lines scrollback consumes 50MB, filling the 64k of the buffer adds another 300MB. There is no way I can sustain my 45 opened terms as of this minute with that kind of memory usage)

On the other hand, I don't ever go very far with mod+pgup, so I was thinking a hybrid system could be more efficient:

• keep a few pages of scrollback as currently.
• copy lines as they go out of that scrollback into a secondary scrollback buffer as plain text, or even better into a compressed buffer (with some fast algorithm like lz4 or zstd)
• scrollback actions like mod+pgup cannot go past the normal buffer so there is no change here, but the pager scrollback buffer would get its input from both buffers concatenated

In my opinion, that secondary buffer should not be processed at all on resizes etc and just be kept as plain text; for correctness I might actually suggest to fold the scrollback lines back into one when they are line continuation.

code-wise this isn't as clear to me as the selection code, but I suspect historybuf_push could use line_as_unicode/line_as_ansi just before overwriting the string and pushing to the secondary buffer, controlling its size at this point ; not sure how to decide if unicode or ansi there?
On the display side, as_text would just concatenate both, the line count should work out on its own... And the secondary buffer would live happily only in the C side.

(And as bonus, it would become easy to have this secondary buffer backed by a file if someone wants an unlimited buffer like #884 asked ; not that I would do that part)

Anyway, just like the other issue, I'd like to get an opinion before starting anything.