After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710483 - Restricting scrolling sometimes doesn't work
Restricting scrolling sometimes doesn't work
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.34.x
Other Linux
: Normal normal
: vte-0-36
Assigned To: VTE Maintainers
VTE Maintainers
[fixed-0-36][needed-next][commit:98b5...
Depends on: 710484
Blocks:
 
 
Reported: 2013-10-18 23:22 UTC by Egmont Koblinger
Modified: 2014-04-06 18:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix (1.52 KB, patch)
2013-10-19 00:21 UTC, Egmont Koblinger
none Details | Review
Fix v2 (1.52 KB, patch)
2013-10-19 00:34 UTC, Egmont Koblinger
committed Details | Review

Description Egmont Koblinger 2013-10-18 23:22:46 UTC
If you try to restrict scrolling with the upper bound being row 1, before the terminal first starts scrolling then it doesn't work.

Start vte, execute  echo -e '\e[1;15r'  immediately, or somewhere in the first 23 rows (before the contents would begin to scroll).  Life goes on as if this command had no effect, scrolling is not restricted to rows 1-15.
Comment 1 Egmont Koblinger 2013-10-18 23:53:19 UTC
If we want the lines scrolled out at the top to be added to the scrollback buffer (and I guess we do want it, this is what xterm does) then the problem is the following: we can have data that should be part of the scrollback (not visible when scrolled to the bottom), but there are unused lines at the bottom (not belonging to the ring). Positioning the ring such way is currently not supported at all by the logic that figures out the scroll offset.

Probably the right solution is to fill up the ring with empty lines all the way to the bottom. It's easy to do it one-shot, but would be tricky to maintain after a resize (cf. bug 710484 which is probably the simplest solution here).

The refactoring idea mentioned in bug 708213 comment 29 might be relevant here, and probably would make this case a little bit simpler too.

(It's also broken in vte-0.34.8, which means that it was not me breaking it with all those recent patches regarding the scroll position that went into 0.34.9.)
Comment 2 Egmont Koblinger 2013-10-19 00:21:19 UTC
Created attachment 257676 [details] [review]
Fix
Comment 3 Egmont Koblinger 2013-10-19 00:34:52 UTC
Created attachment 257677 [details] [review]
Fix v2

Those extra rows should not be filled with the default background (and not be filled at all).
Comment 4 Christian Persch 2013-11-18 18:45:08 UTC
Fixed on vte-0-36.