Mouse-wheel scrolling broken by -X in $LESS
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar Pager Plugin |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
bzr-pager sets the -X command line option (via the LESS environment variable prior to filtering output through the less program). This means that in terminals that support scrolling using the mouse-wheel (such as gnome-terminal) do not work as expected when the pager is running.
One possible fix for this would be to not set the -X flag to less. However, then any output that is less than a full screen will not display at all (well, technically it will display for an instant and then go away) because the -F flag is set. Additionally, the removal of the -F flag would make it extremely inconvenient to work with the output of commands that are less than one full screen-length, because then you'd have to exit the pager every time.
Probably the proper way to fix this (though I am not sure if it is possible in the context of a bzr plugin, since I don't know the bzr code pretty much at all) would be to only actually invoke the pager if the output is more than a single screen. "More than a single screen" can be defined as:
* Longer than $LINES lines, if $LINES is set.
* Longer than $(stty -a | head -n 1 | awk '{ print $5 }' | tr -d ';') lines, assuming the number is non-zero.
* Longer than 24 lines, if neither of the above are usable.
Also, the pager probably shouldn't be run on a terminal that is lacking functionality to actually make use of it (such as a hardcopy terminal) but that is most likely a separate bug altogether.
| Changed in bzr-pager: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
Looking at the bzr-plugin source, one potential method of implementing it would be to cache the output to a temporary file. After the output is in the temporary file, it can be determined whether or not it is shorter than a single screen using the three rules in the bug description, and if it is shorter than a screen length, it would just be output to the terminal directly. Otherwise, the pager would be run on the temporary file. This could be a problem, though, when running commands that have the potential to output more data than might be available in /tmp, especially if /tmp is a memory-backed RAM-based filesystem such as tmpfs.
A less resource-intensive method of doing this might be to take the output of the command as a stream and count the number of lines, and as soon as the number of lines read is (screen_