Mouse-wheel scrolling broken by -X in $LESS

[Michael B. Trausch]

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.

[Michael B. Trausch (mtrausch)]

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_length_lines + 1) lines, decide to invoke the pager. Again, I don't know the feasibility of that sort of thing in the context of bzr architecture, but I imagine one or the other would be possible.