Kitty: Please allow indefinite scrollback lines

[rrthomas]

(Also, I suggest, a good default!)

Something like setting scrollback_lines to -1.

Thanks for kitty!

[kovidgoyal]

kitty currently stores scrollback in RAM (memory is allocated as needed). I dont much like the idea of a terminal taking up unbounded amounts of RAM. So in order to implement this one would need to implement some kind of archival onto disk, which is rather a lot of work. Not something I feel is justified, at least personally. But patches are welcome! If someone wants to tak eup this project, feel free to comment and I will provide any needed guidance.

[rrthomas]

"Archive on to disk" is virtual memory. I'm not sure what would be improved by doing this explicitly. I've never had any problem with gnome-terminal's support, which doesn't store scrollback on disk, and I get some pretty long-running terminals with large scrollback buffers.

Quite happy if you don't agree this should be the default.

[kovidgoyal]

I tend to run computers with no swap -- so for me archive on disk is not the same :) You can simply use an arbitrarily large number. IIRC that setting is stored in a 32bit unsigend int, which means you can have a maximum 4294967296 lines. Assuming you generate a line every second on average, that would give you more than 100 years worth of scrollback history.

[kovidgoyal]

Although I must say, that I dont recommend doing that. When resizing the window, kitty resizes the scrollback as well, so the time taken to resize is proportional to the size of the scrollback

[rrthomas]

I can use an arbitrarily large number, it's just not very elegant (at least, one has to do the sort of calculation you do above).

Not using swap is atypical, but of course you can configure for that use case.

The only real problem here seems to be the resizing of the scrollback. I guess one would want to make that incremental to support indefinitely large scrollback. Although, I hardly ever resize windows.

[kovidgoyal]

Well, I'm a theoretical physicist by training, so that calculation was recreational for me :) What I can do is change the config parsing code, so that negative numbers automatically become the largest possible number. The slow resize and RAM exhaustion problems do remain however.

[rrthomas]

I'm happy to see at what point they become a problem, and then look into fixing them. As you point out, I'm unlikely to generate more than 4 billion lines of scrollback in a single session.

However, there does appear to be a problem. I set scrollback_lines to 1000000000 (1 billion), and my computer ground to a halt when I launched kitty, eventually killing the task (I presume that was the OOM manager). I then reduced it to 10000000 (ten million), and the terminal started up with 111Mb resident and 33.7GB of virtual memory. That sounds as though rather a lot of memory has been allocated up front, rather than just as needed.

[rrthomas]

I then reduced it further to 1 million, and I see a noticeable pause on resizing the window, even with no scrollback yet generated. At this point there's about 3.6Gb allocated and 60Mb resident.

[kovidgoyal]

There is a bug that is causing pre-allocation of the history buffer, wait for me to fix it and then try.

[kovidgoyal]

Should be fine now.

[rrthomas]

Great, thanks! With both 10M and 1G lines of scrollback configured, kitty now starts up with about 300MB of VM and 55MB resident, and no slowdown on resize. I'll see how things go as my sessions get older.

[egmontkob]

I've never had any problem with gnome-terminal's support, which doesn't store scrollback on disk

This is a false statement, gnome-terminal (vte) _does_ store its scrollback on disk (in compressed, encrypted, unlinked files.)

[rrthomas]

Thanks for the correction!