Whole scrollback in one file, O(1) rewrap
@egmontkob
Submitted by Egmont Koblinger Link to original bug (#741520)
Description
Inspired by
- https://bugs.kde.org/show_bug.cgi?id=196998#c20
- recent changes to the stream (bug 738601)
- and following the concept of my recent mcview rewrite https://www.midnight-commander.org/ticket/3250
Let's merge attr changes into text_stream, and drop row_stream entirely. The whole ring would be stored in a single file. Wrapping paragraphs to lines would happen on demand for the visible part (and a bit more as necessary) only.
We could insert some additional metadata at every fixed offset (practically once per boa block), like an ever-increasing paragraph count, the current attributes, convenient offset to the previous newline, etc.) This could be encrypted independently from the rest of the boa block, so we don't have to read/decrypt/decompress a full 64k to get this small piece of info.
Advantages
- Immediate resize with reflow (assuming paragraphs of sane lenghts)
- Only 1 fd per vte, bit smaller overall disk usage
- Simpler design/implementation (or not?)
- Scrollback size would be specified in paragraphs, so no longer drop data or leave partial line at the top on a resize.
- Better change to get recovery after a disk full finally work flawlessly
Disadvantages/gotchas
- Rendering might slow down a bit when giant paragraphs are encountered and you scroll back. Or (like in the mcview rewrite) there could be a safety cap: if we need to traverse more than 1MB backwards to find a newline then we give up and just render it starting randomly
- We'd need a safety upper limit on the stream size (in bytes, computed from the scrollback paragraphs) not to eat up disk on oversized paragraphs.
- The scrollbar wouldn't move evenly, as its position would correspond to the paragraph rather than the line. We'd need to decouple scroll_delta from the widget's vadjustment, and insert an additional layer in between which maintains the current line offset within the paragraph. (Shift+PgUp and friends would of course still scroll by a fixed amount of lines not paragraphs.)
- Dragging the scrollbar would require a binary search in the stream, to find the required paragraph counter.
- Searching in the scrollback would be trickier due to inlined attributes.
Not sure if it's worth it. Not even sure that I'd go this direction if I started from scratch, but probably I would.
Version: 0.39.x