GNOME Bugzilla – Bug 160127
text later than scrollback does not display
Last modified: 2021-06-10 13:11:26 UTC
1. scroll up a little, so you're looking at some particular text 2. produce some more text in the terminal, without scrolling 3. when enough text is produced that the text you are looking at would scroll off the top, cover and uncover the part of the window. The text does not get refreshed. Either the text you're looking at should never be freed (ideal), or when there's so much scroll that your text would be freed, you should just see the top lines of text (so text would be scrolling by).
*** Bug 164664 has been marked as a duplicate of this bug. ***
This is an issue in vte. Indeed, you can reproduce it using the vte app that is built with the lib. To see it happen, open vte and say, assuming your SHELL is bash: for a in `seq 100`; do echo $a; done; sleep 3; for a in `seq 10000`; do echo $a $a $a; done in a shell. When the you see the 100 number, scroll up a bit. Moving to vte and updating version et al. since this happens with HEAD.
Created attachment 80784 [details] [review] Expand the scrollback buffer to maintain the top line in history. <mariano> keeping the scrollback as big as the row count should fix that, more or less, no? <ickle> actually, I was thinking of scrolling such that the last line of the scrollback history was visible otherwise the scrollback buffer might get a tad large <mariano> to have the text scroll by would change the behaviour muchly <ickle> I was thinking it might have been more consistent UI wise <mariano> consistent with what? <ickle> current, if you scroll afterwards you jump several pages if the last line of the scrollback history was always visible there would be no jump what you see is what you get. <mariano> yup, but every time I scroll up I really want what I see to be there until I decide not to look at it anymore I do that all the time while compiling stuff, for example in most situations, the output would go so fast that the scrollback would be essentially useless for that
Expanding the scrollback is not going to work, as if you for example scrollback one line while running jhbuild and leave the box unattanded, then scrollback is going to grow to hold the whole output! Can we have a buffer for the currently displayed lines, so that we can repaint the screen, but keep the buffer as it is now?
I think I see what you mean, but I've exhausted myself with the mental excercise that was _vte_ring_grow and I need some sleep. I can see that there will be many use cases to statisfy here... For example, I occasionally want it to buffer the entire jhbuild - who wants to mess around with log files! Or perhaps it would be useful to have an automatically resized buffer in synaptic [the update terminal window]. Quick idea: introduce a displayed_rows[row_count] array of row_data + displayed_delta. This requires refcounted rows and could tie into a new row allocator designed to reduce memory fragmentation... [Okay we could just copy the row_data, but where would the fun be in that?]
The only good solution I can think of is to scroll the scrollback too... 1 2 3 4 5 6 < 7 < visible window 8 < scrollback: 1 2 3 4 < 5 < visible window 6 < 7 8 output occurs: 1 2 3 4 5 < 6 < window is relatively in the same position; 2 units up, 7 < but there is more output... 8 9 This is at least how I'd expect a scrollback to work when more output arrives. Of course, buffering the visible area is also an option; increasing the buffer with the output isn't really viable though, imagine a day full of compile-time output... I wouldn't mind an option to choose between a scrolling window and a buffered visible area. And maybe continuously growing buffer as a third option (or maybe scrollback logging to file -- that way we won't waste a lot of RAM).
*** Bug 413104 has been marked as a duplicate of this bug. ***
Growing scrollback may make more sense if we change vte to keep scrollback buffer in an mmapped file like konsole does.
Still reproducible on vte master.
I can try to fix this. However, this can cause your machine to run out of disk space if we essentially turn a limited scrollback into unlimited just because you left the scrollbar up there. What do people think? The code to lock the scroll is also needed for real asynch history save. It's much safer now though. Before it could cause out-of-memory if we tried that.
I don't think running out of disk space is any big concern. A screenful (typically 80x60 or so, perhaps?) is around 10kB. Thousand screenfulls would thus be 10MB. A normal harddisk these days, on a laptop, is what, 100GB?
Build logs can grow too large too fast. And it goes to your /tmp, which is not necessarily huge. I probably cap it. But I generally agree.
The problem for me is not having access to text that is actually on the screen. All of the scrollback doesn't need to be buffered, just the area that is actually visible. Caching the contents that are actually visible would allow me to continue to interact with the window, without degrading functionality. I could cover/uncover it without losing text. Viewing text off the top of the buffer would need special handling this way. The scroll state is kind of off the top of the scrollbar. Scrolling anywhere would lose the text off the top and jump back to the buffered text. This would solve my use-case. When I'm getting a large amount of mostly uninteresting scroll, sometimes there's a bit of interesting stuff that I want to keep and work with for a while. Maybe I get called away from the computer for a few hours and when I come back the bit I was working with is far, far off the top of the buffer. I don't need the bits in between, I wasn't working on them. If I needed them I would have piped to a file. I could see people needing those missing bits. Having an option to send them to a file might be nice for them. Maybe even all of the bits that fall off the top of the buffer (even when they aren't scrolled back) until the window or tab is closed. What happens when the disk gets filled? For my case, now we're back to my original problem. I think this is a totally separate problem and use-case. I just want the currently viewed text to be cached. For me, that is 80x24 = 1920 chars and of minimal impact to memory usage.
I agree that Sean's use case in comment 12 is probably a typical one, and the solution he outlines in his previous comment is probably the right way to go. We already have infinite scrollback (and if you choose that, you no longer have this problem). But if you choose to have a finite one, the scrollback code should obey that and not make an exception when you happen to be scrolled back, so it shouldn't begin to temporarily remember everything. Still, having the current content stay on would be desirable. Also I find David's suggestion in comment 7 to be of not much use. Obscuring and exposing a window generally shouldn't change its contents. I tend to use this combo to get rid of temporary glitches (e.g. browsers often leave some faulty pixels behind). I wouldn't expect this combo to do the opposite of fixing the display: breaking it instead. Sean's addition could relatively easily be implemented: have another row_count pieces of VteRowData that contains this region once it's scrolled out. Then it's easy to repaint the screen from this. A couple of minor details to take care of: Probably any change to scrollbar position should drop this data for good and bring the viewport back to within the current scrollback content. Same should happen on window resize. Increasing the number of lines wouldn't work as we'd have no data to fill up the new lines with. Rewrapping (bug 336238) would be terribly hard to do. Let's just forget about these. We should disable mouse highlighting to scroll the viewport, so you don't accidentally try to extend the highlight beyond the bottom and suddenly lose everything. (Or would it lead to the false belief that the viewport is scrolled to the bottom?) What to do if the number of scrollback lines is changed? Probably not doing anything will be okay and will just leave this content onscreen. A complicated use case is when the number of scrollback lines (note: in vte's terminology it includes the onscreen lines too!) is between row_count and 2 * row_count. Then you can enter this special behavior of remembering the top, but the visible part is still modifiable by application. E.g. you have 24 rows, and a scrollback buffer of 40 lines (i.e. 24 visible + 16 more). Print numbers from 1 to 40, one per line (like "seq 1 40", but without trailing \n or shell prompt). Scroll to the top, you'll se 1..24. Print numbers 41..45. You'll still want to see 1..24. The scrollback buffer contains 6..29, of which the modifiable area is 22..45. Now the application modifies the numbers 22-23-24. These need to be updated. (Perpahs it's not worth fiddling with it, maybe we could just simply force the number of scrollback lines not to fall in this interval?)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/1006.