Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Vincent Lefevre]

On 2019-02-07 20:15:11 +0100, Egmont Koblinger wrote:
> > I'm wondering why this isn't documented in the GNOME Terminal help.
> 
> Because the help pages document the UI, and not the terminal
> emulation behavior.
> 
> It would be practically impossible to provide an exhaustive
> description of the emulation behavior.

But this one is really special as specific to GNOME Terminal.
Now, anyway, it shouldn't be the default behavior.

> > I think that this should be part of the application configuration
> > (e.g. less), which could enable this feature at startup and disable
> > it before exiting.
> 
> That approach would have pros and cons, too. For example, it would
> need to have explicit support from every application;

But this would be needed anyway so that the scroll is done only
in contexts where it makes sense.

> it would only work in those few that actually care enough to
> implement emitting these sequences. Currently it works everywhere.

Well, for applications that do not have any support, it is easy
to write a wrapper script that does the limited work. Thus the
user could choose whether to enable the wheel or not.

> For apps that do care about it, they can implement mouse support so
> that they receive the actual scroll event, and can act on it however
> they wish. E.g. "less" could scroll back by 6 lines on its viewer, but
> jump back by 1 entry in the search input field. You can't do this 6
> vs. 1 line toggling with the 1007 mode.

Yes, and as noticed in

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436186#52

it has recently been implemented in "less" (not yet released), and
one can choose the number of lines:

  https://github.com/gwsw/less/commit/dd8c4cd8208ac7ce3dd9407ead321996ed0fc016

> Consider this feature a dirty hack for non-mouse-aware apps. :-)

And because it has too much drawback in general and its could be
best used with wrapper scripts (i.e. only when it can make sense),
it should be disabled by default.

> I don't think it's a feature GNOME Terminal / VTE designed, by the
> way. I think it originates from xterm, although I'm not entirely sure.

No, it came from GNOME Terminal. In xterm's log:

                            Patch #282 - 2012/09/28

     * add alternateScroll resource and corresponding control sequences
       which modify the scroll-forw and scroll-back actions: when the
       alternate screen is displayed, wheel mouse up/down will send
       cursor keys (Debian #683942).

and in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683942
it is said:

  I used gnome-terminal recently and noticed that using the mouse wheel
  caused scrolling within apps like vim.  I thought that was strange,
  because I disabled mouse support in vim.  It turns out gnome-terminal
  has a feature called "alternate screen scrolling".  When you are in the
  alternate screen, it translates the mouse wheel into three up or down
  arrow presses.

  This is obviously a hack, but I want it.  (I don't like enabling mouse
  support in vim because it takes over the mouse entirely, and as far as I
  understand there is no way for it to only take the wheel.) [...]

The fact that this user wants only wheel support may be a very specific
choice, and he didn't complain that this hack wasn't enabled by default
in xterm.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)