Bug 355106

Summary: button 4 and 5 (e.g. scroll wheel): scrolls bash history or output buffer
Product: [Applications] konsole Reporter: Achim Bohnet <ach>
Component: generalAssignee: Konsole Developer <konsole-devel>
Status: RESOLVED FIXED    
Severity: normal CC: a.samirh78, egmont, nate, simonandric5
Priority: NOR Keywords: usability
Version: 17.08.1   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: https://commits.kde.org/konsole/17c77a8729336c69bdeff970e3674d929b915b17 Version Fixed In: 18.04
Sentry Crash Report:

Description Achim Bohnet 2015-11-09 20:54:00 UTC 
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.


Reproducible: Always

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

Actual Results:  
See 2., 4.  and 6. above

Expected Results:  
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.

Achim
Comment 1 Kurt Hindenburg 2015-11-14 20:35:20 UTC 
I agree it is inconsistent - most other terminal just do the scrollback
Comment 2 Achim Bohnet 2016-09-24 21:55:23 UTC 
'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
Comment 3 Egmont Koblinger 2017-10-03 20:36:57 UTC 
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...
Comment 4 Egmont Koblinger 2017-10-03 20:39:03 UTC 
See also http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Wheel-mice
Comment 5 Ahmad Samir 2018-03-07 20:20:13 UTC 
https://phabricator.kde.org/D11146
Comment 6 Ahmad Samir 2018-03-08 22:50:05 UTC 
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).
Comment 7 Kurt Hindenburg 2018-03-10 18:06:00 UTC 
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

Summary:
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.
FIXED-IN: 18.04

Reviewers: hindenburg

Reviewed By: hindenburg

Subscribers: rkflx, ngraham, #konsole

Tags: #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

https://commits.kde.org/konsole/17c77a8729336c69bdeff970e3674d929b915b17