Open broosa opened 7 years ago
Hi @broosa, the idea sounds good to me. In fact, this is something I've been wanting to do for quite a while (and effectively make HistoryScreen
the default implementation). I know this is about a year late, but I'd be happy to welcome a PR if you have the time to look into this.
This would be a great addition. I wanted to use pyte to replay a file full of escape sequences (installation logs with progress bars, for example). I don't know how many lines I'll need to capture the entire output. Unless there's some other way to do it?
Hi everyone!
I've been thinking it would be nice to extend HistoryScreen so it can have an unbounded history size. I believe the history parameter in
HistoryScreen.__init__()
is used to set themaxlen
of the deques that manage the history buffers. Could we add a special case so thatmaxlen
is not set, allowing the top and bottom histories to grow without bound?Also, has anyone thought of implementing a "sliding window" approach to making a scrollback buffer?
I can see it working something like this:
Console output is stored in a single buffer, which stores all input fed to the terminal emulator. New lines are added to the end of the buffer, pretty much as is done now.
Pagination would done via "views". A view would represent a distinct region of the output buffer, with a height equal to the size of the terminal. If the user wants to "page up", the start can be changed by the height of the terminal, which would change it's position in the output buffer. To get what's on screen you'd just return the lines in the output buffer that are within the screen view area (e.g.
output_buffer[view_start:view_end]
)I know this would probably be a big architectural change, but i think it has the potential to make things a lot simpler and reduce the amount of time spent shuffling strings around. We could also potentially use a feature like that to make it super easy to generate transcripts of sessions in the terminal emulator as well.
Thoughts?