novakane has quit [Read error: Connection reset by peer]
novakane has joined #foot
novakane has quit [Quit: WeeChat 3.3]
novakane has joined #foot
feinedsquirrel has joined #foot
diniwed has joined #foot
<feinedsquirrel>
is there a way to disable the scrollback limit? Currently if I set it to a massive number, foot fails to load with a malloc or something. I'm specifically thinking of a mechanism like termite had, that if I set it to "-1" it would be infinite scrollback. Just wondering if that is possible with foot.
<ifreund>
nothing is truely infinite in the real world
<ifreund>
certainly not your computer's memory
<dnkl>
feinedsquirrel: no, that isn't possible, as it would require writing to a file, or compressing the scrollback (or both). Both options being out of scope for foot (too complex for what we get)
<feinedsquirrel>
ifreund: yes, I understand there are limitations at a certain point, but just the idea that I wouldn't have to set a specific limit.
<feinedsquirrel>
dnkl: cool, thanks for the explanation. out of curiousity, do you know which method vte-based terminals use? (termite, gnome-terminal)?
<dnkl>
Not off the top of my head, but would suspect writing to a file, without compression
<dnkl>
I believe kitty does in-memory compression?
<feinedsquirrel>
dnkl: cool. yeah, I don't expect you to look it up. So is my assumption right that foot pre-allocates, upon window loading, the memory space required for that window?
<dnkl>
feinedsquirrel: yeah, it pre-allocates what's needed by the window itself. As things scroll out, we allocate scrollback memory on-demand
<feinedsquirrel>
Cool, thanks again, for your time!
<dnkl>
Perhaps worth mentioning; it does pre-allocate an array of pointers for the entire scrollback. So, 8 bytes per line
<feinedsquirrel>
dnkl: ah yes, that makes sense. that is maybe why I was seeing that error.
<rcf>
VTE will actually reallocate up until you run out of memory if I recall correctly. It also becomes hideously slow on resizing, eventually taking multiple seconds for a long-lived instance even on modern hardware
<feinedsquirrel>
rcf: that because it has to copy everything into the newly allocated space?
<ifreund>
I only see one function that writes to some kind of output stream, probably a file
<ifreund>
nothing that reads scrollback in from a file
<dnkl>
feinedsquirrel: foot would be slow at resizing too, if you set, and full, a sufficiently large scrollback... ;)
<feinedsquirrel>
ha, yes, I assume as much. And just to make sure I'm understanding, upon window launch, it would allocate i.e. 8MiB of pointers if scrollback lines was set to 1 million lines, then as those lines fill, it would keep an additional 1 byte per character (utf-8) including characters for bold, color, etc?
<rcf>
feinedsquirrel: if only it were actually so simple…. Terminals are awful.
<dnkl>
No... 8 bytes per row is for the pointer only
<dnkl>
Once a row needs to be allocated, it's a number of bytes for the row itself
<dnkl>
Dont remember the exact number
<dnkl>
Then there's 12 bytes per cell (column)
<feinedsquirrel>
rcf: yeah, I was just thinking maybe I should stop while I'm already ahead, and let y'all get back to your day. dnkl: yeah, I understood the pointer-per-row part. Probably the bytes-per-row is dependent on how wide the window is at launch? ... I really should quit asking, and leave you be. I get too curious too easily.