Steps to reproduce:
- Set the windows KB repeat rate to the maximum (about 30 per sec).
- Maximize the console/terminal window, maybe also decrease font size a bit (more content on screen).
- Run some command with big and non-instant output, and pipe it into "less", for instance (in the "less" source dir):
git log --color=always --graph | less.exe -R
- Press and hold page-down.
Expected behavior: it scrolls down as fast as possible, depending on the bottleneck (KB repeat rate, or content input rate).
Actual behavior: same as expected, but with a LOT of "beeps" (most of them interrupt/restart an already-playing prior beep).
While I guess I understand why it happens (the paging is presumably stalled repeatedly due to slow-ish content input), in practice it doesn't feel stalled, and these hundreds of beeps are highly annoying.
I know I could use -Q to silence it, but I do want the beeps (one would be enough) when trying to page above the top or below the actual EOF.
For reference, when piped into (busybox-w32) cat, the same git command completes in ~ 200 ms. So while the git output is not instant, it's still very quick. Way quicker than the time it takes to page-down till EOF in "less" (~ 13 seconds with my repeat rate and terminal size).
Assuming it's agreed that largely this shouldn't happen, because it seems the main reason for the stalls is the way "less" itself reads the content input rather than the actual content throughput, I'm not sure what would be the best approach to address it.
Technically, at least with this specific example, if "less" did some readahead (at the extreme, for the whole content in ~ 200 ms) then it might mitigate some or all of it.
Another option is maybe to not beep until some time (say, 500 ms?) has elapsed since the stall without further input arriving.
Another option is maybe to consider whether the KB input queue is empty or not. For instance, after a single page-down (nothing more at the KB input queue), if the content input not ready then do play a beep, but if I'm holding page-down (and the KB input queue is not empty), then maybe just one beep is enough.
Not sure what's the best approach. It might need some experimentations and thought. But these beeps do feel largely unexpected to me, and depending on point of view, also unnecessary.
Steps to reproduce:
git log --color=always --graph | less.exe -RExpected behavior: it scrolls down as fast as possible, depending on the bottleneck (KB repeat rate, or content input rate).
Actual behavior: same as expected, but with a LOT of "beeps" (most of them interrupt/restart an already-playing prior beep).
While I guess I understand why it happens (the paging is presumably stalled repeatedly due to slow-ish content input), in practice it doesn't feel stalled, and these hundreds of beeps are highly annoying.
I know I could use
-Qto silence it, but I do want the beeps (one would be enough) when trying to page above the top or below the actual EOF.For reference, when piped into (busybox-w32)
cat, the same git command completes in ~ 200 ms. So while the git output is not instant, it's still very quick. Way quicker than the time it takes to page-down till EOF in "less" (~ 13 seconds with my repeat rate and terminal size).Assuming it's agreed that largely this shouldn't happen, because it seems the main reason for the stalls is the way "less" itself reads the content input rather than the actual content throughput, I'm not sure what would be the best approach to address it.
Technically, at least with this specific example, if "less" did some readahead (at the extreme, for the whole content in ~ 200 ms) then it might mitigate some or all of it.
Another option is maybe to not beep until some time (say, 500 ms?) has elapsed since the stall without further input arriving.
Another option is maybe to consider whether the KB input queue is empty or not. For instance, after a single page-down (nothing more at the KB input queue), if the content input not ready then do play a beep, but if I'm holding page-down (and the KB input queue is not empty), then maybe just one beep is enough.
Not sure what's the best approach. It might need some experimentations and thought. But these beeps do feel largely unexpected to me, and depending on point of view, also unnecessary.