Opening a new shell konsole and using the mouse wheel -> scrolls through bash history. As soon
as there is a scrollback buffer the mouse scroll wheels scrolls through the scrollback buffer.
Steps to Reproduce:
1. Open a new konsole shell
2. Use scrollmouse -> in the line with the shell prompt, one sees the bash history scrolling
3. File scrollback buffer. e.g. ls -l /usr/bin
4. Use scrollmouse -> konsole tab scroll thrugh konsole's scrollback buffer
5. View -> Clear Scrollback
6. Use scrollmouse -> in the line with the shell prompt, one sees the bash history scrolling
See 2., 4. and 6. above
In Case 2. and 6. nothing should happen, because there is nothing to scroll back
IMHO above behaviour here is inconsistent. Delegating scrolls to the application should not depend if the is a non-empty scrollback buffer. It should only use 'full-screen' mode as set by e.g. less, top or vim, as a trigger to delegate scroll effents to the application.
I agree it is inconsistent - most other terminal just do the scrollback
'Bug' still in 16.08.3. ( bash with readline in vi mode)
How about this:
* scroll events always navigate in the history buffer
* shift-scroll events: navigates in shell history
I absolutely agree that this behavior is misleading.
bash isn't interested in mouse events, doesn't turn on mouse support and hence doesn't receive mouse scroll events. What happens is that konsole translates these events into Up or Down keypresses. (You can confirm this e.g. by running "cat" before the scrollbar appears, and then rolling the wheel.)
This feature is called "alternate scroll mode" and is meant to kick in on the alternate screen only, and only when mouse support is turned off. It boosts usability of several mouse-unaware apps (e.g. "less"). Even its name implies that it shouldn't be enabled on the normal screen where bash is running.
Emulators might allow to toggle this feature by some preference setting (I couldn't find such in konsole) or via DEC(RE)SET 1007 which isn't supported by konsole.
I personally don't think I find the idea of Shift+Scroll synthesising Up/Down keypresses useful. I mean, if you need to reach out to the keyboard at all, why not use the regular Up / Down keys...
See also http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Wheel-mice
FWIW, it seems that xterm was inspired to add the alternateScroll resource to send up/down key events for mouse scroll wheels by gnome-terminal and konsole, c.f. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683942 (IIUC, anyway).
Git commit 17c77a8729336c69bdeff970e3674d929b915b17 by Kurt Hindenburg, on behalf of Ahmad Samir.
Committed on 10/03/2018 at 18:05.
Pushed by hindenburg into branch 'master'.
Only emulate up/down key presses for mouse scrolls on alternate screen
Konsole sends up/down key press events for mouse scrolls for apps that
aren't interested in mouse events, such as less. Only do this when the
terminal is using the alternate screen.
Now scrolling up/down will be translated to up/down key presses only
when the terminal is using the alternate screen but scrolling in a terminal
using the primary screen will only scroll using the scrollbar, now it does
not cycle through the shell history.
Now the behavior matches xterm and and gnome-terminal.
Reviewed By: hindenburg
Subscribers: rkflx, ngraham, #konsole
Differential Revision: https://phabricator.kde.org/D11146
M +2 -0 src/SessionController.cpp
M +11 -5 src/TerminalDisplay.cpp
M +10 -0 src/TerminalDisplay.h