GNOME Bugzilla – Bug 538195
vte and gnome-terminal don't allow disabling of keystroke scroll for alternate screen
Last modified: 2014-01-10 10:54:07 UTC
vte has a feature where scrolling in an alternate screen (or when scrolling is restricted) causes Up/Down keystrokes to be sent instead of normal scrolling. This feature can be very annoying when using some applications like mutt or screen. Alternate screen keystroke scrolling should be configurable so that the user can turn it on or off. Other information:
Created attachment 112704 [details] [review] vte patch to turn feature on or off Here is a patch to add the ability to toggle alternate screen keystroke scrolling.
Created attachment 112705 [details] [review] gnome-terminal patch to configure the feature Here is a patch for gnome-terminal that allows the user to configure turning the feature on or off.
Created attachment 112711 [details] [review] Unified diff for vte patch
Created attachment 112712 [details] [review] Unified diff for gnome-terminal patch
What kind of work does the patch need?
Created attachment 112948 [details] [review] Fixed gnome-terminal patch Sorry, I didn't realize how much trunk has changed from 2.22.2. This new patch has been made against trunk.
Not sure I like the idea in this bug. Just don't scroll in those windows if you don't like it. What's wrong with that?
(In reply to comment #7) > Not sure I like the idea in this bug. Just don't scroll in those windows if > you don't like it. What's wrong with that? Well, in the case of mutt, an occasional accidental scroll results in mutt going through most of my mail and marking it read. In the case of screen, I like to be able to scroll regularly through the terminal history, rather than having it skip through my bash history. I'm sure that there are plenty of other annoyances that are caused by this feature, these are just the two that really stick out to me, and I am not alone. A quick google found: http://ubuntuforums.org/showthread.php?t=491256 https://bugs.launchpad.net/ubuntu/+source/screen/+bug/106995 I know that I came across more things like those while I was trying to figure out where the problem was. The solutions suggested in those discussions don't really solve the problem, which really is the up/down keystroke feature that was added to vte. I understand that some people find it to be a great feature, but I, as well as at least some others, find it to be an annoyance. I don't have a problem with it being there, even on by default, I would just like the ability to turn it off. Considering that it seems to be an arbitrary feature that was added because some users liked it, it seems reasonable to me to make it configurable so that others can simply turn it off.
Even if you disable this feature, you get no scrolling in screen.
(In reply to comment #9) > Even if you disable this feature, you get no scrolling in screen. This is not true. With mutt, you get no scrolling, that is true. Scrolling in screen works fine. Of course, scrolling is through the terminal's history, not the screen's history, but that works fine for me most of the time. I assume it is the difference between having scrolling restricted (which looks to be the case with mutt?), and simply drawing on the alternate screen (which looks to be the case with screen).
(In reply to comment #10) > (In reply to comment #9) > > Even if you disable this feature, you get no scrolling in screen. > > This is not true. With mutt, you get no scrolling, that is true. Scrolling in > screen works fine. Of course, scrolling is through the terminal's history, not > the screen's history, but that works fine for me most of the time. I'm pretty sure this is not the case. If it is, then it's a bug in vte. vte should send keystrokes for scroll only if/when the scrollbar is inactive. I had another user claim the same as you and he agreed with me after he tried it. Whether you get a disabled scrollbar in screen depends on your terminals termcaps as screen see it.
(In reply to comment #11) > I had another user claim the same as you and he agreed with me after he tried > it. Whether you get a disabled scrollbar in screen depends on your terminals > termcaps as screen see it. Ah yes, I forgot about that. I am using termcapinfo xterm ti@:te@ in my .screenrc, without which the scrolling is disabled. But I think that we are digressing from the topic: The emulated keystroke scrolling should be configurable, regardless of possible (and in the screen case, not really satisfying) individual workarounds for a given application.
My point is: disabling this feature in g-t does NOT give you scrolling back.
(In reply to comment #13) > My point is: disabling this feature in g-t does NOT give you scrolling back. Hmm. I hate to just keep going back and forth about it, and I think that I follow what you are saying, but: disabling it _has_ given me scrolling back, at least in an acceptable way, combined with termcapinfo xterm ti@:te@, I can scroll back through the terminal's history of what screen has placed down. This behavior is what I have become accustomed to and it works out really nice for just quickly looking back at what has scrolled by. By the way, sorry that the unified diff vte patch has an incomplete change to doc/reference/xml/vte.xml. Between making the first patch and redoing it in unified format, I had attempted to update the documentation but it looks like it is autogenerated in some way that I couldn't figure out and I forgot to revert that file before re-diffing. I haven't looked at how different 0.16.14 is from trunk, but I am willing to write a new patch against trunk if it will help. I'll also update the documentation if you can explain to me how it works.
You keep missing the point. With current code doing "termcapinfo xterm ti@:te@" gives you scrolling back too.
(In reply to comment #15) > You keep missing the point. With current code doing "termcapinfo xterm > ti@:te@" gives you scrolling back too. I disagree, it does not give me scrolling back (I really did just test it). But I think that you are missing my point: The feature should be configurable so that the user can choose to not use it. This specific case is only marginally relevant in that it is one of the annoyances that I am personally experiencing involving the feature.
Heath is correct afaics, I have had that termcapinfo in my .screenrc for some years now and then about a year ago the behaviour of vte changed and instead of scrolling through scrollback, my mouse wheel scrolled through my bash history. see https://bugs.launchpad.net/ubuntu/+source/screen/+bug/106995 (my comment, #4, shows the point in time when I first encountered this). No combination of the ti@:te@ screenrc option, or its altscreen setting, lets me bring back the proper scrolling in Screen.
I don't know why this was closed. You guys must have no idea how annoying this is. I can barely use vim because of this. And I =cant even turn it off=. I guess it's back to urxvt-unicode till this =bug= is fixed.
I am reopening this bug in light of the two most recent comments. Please don't dismiss this problem, it is a serious annoyance for some users.
What Heath said. I live in a terminal running screen to toggle b/w mutt, emacs, vim, bash, etc. This new feature is driving me nuts - I would like to be able to disable it.
(In reply to comment #20) > What Heath said. I live in a terminal running screen to toggle b/w mutt, emacs, > vim, bash, etc. This new feature is driving me nuts - I would like to be able > to disable it. Can you please elaborate why can't you simply not use your mouse's scroll feature then? In other terminals, it doesn't do anything inside screen, right?
*** This bug has been marked as a duplicate of 518405 ***
I don't have any particular problem with screen, I was just explaining the nature of my work environment. I don't want the mouse to send keystrokes to my console apps. I use sloppy focus and am becoming increasingly aware of my habit of nudging and bumping mouse buttons accidentally while moving the mouse. If the mouse pointer is moving over my browser and I accidentally scroll it doesn't matter. The page moves up or down a couple of lines, I probably won't even notice. If I roll over a terminal running mutt and the keystrokes generated by unintentionally rolling the scroll wheel cause mutt to mark a dozen messages as read that is really annoying. This happens to me several times a day. It was not immediately obvious what the problem was, I just kept seeing things happen in my terminal that I couldn't account for. Once I realized what was actually happening I tried to disable the feature but that is not currently possible. It is simply too easy to send destructive input to my terminal by bumping the scroll wheel to regard being more careful with my use of the mouse as a reasonable solution to the problem. I will either switch to xterm or stop using a scroll wheel mouse.
Behdad: Regarding "In other terminals, it doesn't do anything inside screen" - with a default screen setup scrolling in xterm does indeed do nothing, while in VTE it scrolls command history. Setting "termcapinfo xterm ti@:te@" in screenrc causes screen to send its scrollback to the terminal, at which point scrolling in xterm scrolls though the scrollback. Scrolling in VTE still scrolls through command history. Basically I find the command history scrolling very unhelpful. I can see how it can be useful in things like vim where you end up causing vim to scroll through the file, instead of scrolling through the terminal's scrollback, but for me the negatives outweight the positives and I would prefer it if scrolling always meant going through the scrollback. vim has perfectly useful movement keys and I use them.
Count one more person who finds this feature very frustrating. Please allow me to disable it! I've tried termcapinfo ... ti@:te@ in my .screenrc, and it has no effect. xterm works just as I want it, but vte-based terms (xfce4 terminal, sakura) are broken for my normal use pattern. It took me quite a bit of searching to find this bug report, which explains this crazy behavior. It seems that there may be some confusion about the actual symptom. The terminal behaves correctly when not using GNU screen. In this case, I can open a new terminal, type 'ls -R /etc', and using the mouse wheel in the middle of the terminal window will scroll back in the terminal buffer. This is the desired behavior. However, if I run GNU screen, and then perform the same actions, the mouse wheel sends the up- or down-arrow sequence (5x ^[[A or ^[[B). SHIFT-wheel sends 5x ^[[1;2A (I'm not sure what that's useful for, at least zsh and vim don't understand it). I've tried with combinations of .screenrc settings "term xterm", "term screen", "terminfo xterm ti@:te@", etc. None of them has any effect on this. Please fix this so that it works the same in screen as it does out. Or, remove the feature, or allow users to disable it easily.
This is a serious PITA for me every day. I am considering switching from Ubuntu to Windows for this reason alone! I don't believe this is a duplicate, this bug appears to be more about configuring the terminal to disable the mouse. Personally I would just like to disable the mouse scrolling. Here is a usage scenario: I have irssi (via ssh,screen to my server) inside of gnome-terminal. I am typing in irssi (inside my terminal) and my thumb (part by the hang) hits the touchpad of my laptop. Now my irssi history scrolls back and if I hit enter (because it is the next character in my thought process) I end up posting something from my history in IRC. This happens every day, usually 20-25 times during the day for me.
I have this same issue now with gnome-terminal+mosh. Using xterm works fine and scroll actually scrolls the screen, not bash commands. System: Ubuntu 12.04 with latest updates installed.