Allow disabling wheel input

[GoogleCodeExporter]

I would like to be able to control whether using the mouse wheel will send 
whatever input it does send (is it just a few up/down arrow key presses?).  
The laptop I am using makes it easy for me to accidentally scroll with the 
trackpad while I am typing, and I find that my insertion position in vim 
often moves about if I am not careful. :)  So an option in the Mouse pane of 
the options window to disallow mouse wheeling would be useful.

Thanks.

Original issue reported on code.google.com by hey...@gmail.com on 7 Mar 2010 at 11:29

[GoogleCodeExporter]

Isn't that an issue in other apps too, i.e. wouldn't you be better off to 
globally
disable trackpad scrolling?

Original comment by andy.koppe on 7 Mar 2010 at 11:33

[GoogleCodeExporter]

It is true that this is a global issue, but I find that it affects me most when 
working in terminal windows (where I'm mostly doing text editing).  This is 
probably 
because other Windows apps tend to just scroll the window when performing 
trackpad 
scrolling, rather than moving the current input position.

I notice that in, for example, bash the mouse wheel will scroll the scrollback 
buffer 
as if using the scroll bar in the window, while in some programs (like mutt or 
vim) 
that the wheel sends some input to the program to perform in-program scrolling. 
 I 
guess that is an xterm feature?  (Is it related to "application mouse mode"?)  
Perhaps an option to disable that mode and have it unconditionally scroll the 
scrollback buffer would be useful for other people?

Original comment by hey...@gmail.com on 7 Mar 2010 at 11:42

[GoogleCodeExporter]

The mousewheel sends cursor keys if the application has enabled the so-called
"alternate screen" but not xterm mouse tracking (which mintty refers to as
"application mouse mode" and where mouse events are reported using different
sequences from the keyboard ones). Xterm doesn't have the mousewheel-to-cursor 
key
feature, but I think Konsole and gnome-terminal do.

Anyway, the option you suggest in your last question already exists: "Enable
scrollback on alternate screen" on the Window page.

Original comment by andy.koppe on 7 Mar 2010 at 11:55

[GoogleCodeExporter]

I think my ideal solution would be if I could keep scrollback disabled on the 
alternate 
screen, but to also not translate the mouse wheel to cursor keys.  But enabling 
scrollback is good enough for my purposes: I might get errant scrolls still, 
but at 
least my cursor position won't change and the window will scroll back down to 
the 
bottom when I type the next key.  Thanks!

Original comment by hey...@gmail.com on 7 Mar 2010 at 11:59

[GoogleCodeExporter]

Yet with scrollback on the alternate screen enabled, my original point about 
this 
being an issue affecting any Windows app holds again. Have you looked into 
things 
like http://code.google.com/p/touchfreeze to tackle this? Or perhaps the 
touchpad 
driver has a relevant option somewhere?

And if the accidental scrollback is annoying in vim, isn't in equally annoying 
in 
bash too, i.e. would it really help to disable the mousewheel-to-cursor-keys 
feature 
only?

Leaving this open at priority 'None' to see whether there's more demand.

Original comment by andy.koppe on 10 Mar 2010 at 8:25

• Changed state: Accepted
• Added labels: Priority-None

[GoogleCodeExporter]

I agree with you that inadvertent scrolling with the trackpad is a system-wide 
issue.  All I found was that it is a 
mild annoyance most of the time, but a definite problem when using vim in a 
mintty with mouse wheel events 
being sent as up/down arrow keystrokes.  The difference being that the latter 
will change the current insertion 
position so in the middle of typing my input will start being inserted on a 
different line.

In bash, using the wheel / trackpad scrolling only scrolls the buffer, it 
doesn't send the up/down keystrokes, 
so this falls in the "mild annoyance" category -- as soon as I continue typing 
the window is scrolled back down 
to the last line again.

So your suggestion of making the wheel scroll the buffer when the alternate 
window is showing transforms the 
problem in vim to be a mild annoyance one.  One that I can live with. :-)

The Apple trackpad drivers do have this "palm rejection" mode, and I have it 
switched on, but it doesn't seem 
to work all of the time.  Thanks for the pointer to touchfreeze; I'll check it 
out.

Original comment by hey...@gmail.com on 10 Mar 2010 at 10:01

[GoogleCodeExporter]

Mintty 0.7 no longer has the "Access scrollback from alternate screen". It's 
replacement is the new 'Flip Screen' command for switching between primary and 
alternate screen. See issue 174.

'Flip Screen', however, doesn't address the issue with inadvertent mousewheel 
scrolling  described here. Therefore I've decided to add a control sequence for 
disabling and enabling mousewheel reporting on the alternate screen:

\e[?7786l   disable
\e[?7786h   enable

It remains enabled by default. You could either disable it globally, by 
sticking 
"echo $'\e[?7786l'" into a shell startup file, or on an app-by-app basis, e.g. 
by 
putting this into .vimrc:

let &t_ti.="\e[?7786l"
let &t_te.="\e[?7786h"

Implemented in r844 on trunk.

Original comment by andy.koppe on 17 Apr 2010 at 1:56

• Changed state: Fixed
• Added labels: Difficulty-Easy, Priority-Low
• Removed labels: Priority-None

[GoogleCodeExporter]

Original comment by andy.koppe on 17 Apr 2010 at 1:57

• Added labels: Milestone-0.7

[GoogleCodeExporter]

Original comment by andy.koppe on 3 May 2010 at 7:42

• Changed state: Verified

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

If you see this issue in gnome terminals. Try this:
Goto the terminal menu "Edit > Profile Preferences > Scrolling".
Uncheck "Use keystrokes to scroll on alternate screen".

Original comment by webberti...@gmail.com on 4 May 2010 at 6:24