Some terminal applications use the alternate screen, which is the
equivalent of

  printf "\033[?47h"

When it is used, using the mouse wheel (up / down) sends 6 kcuu1 / kcud1
escape sequences (corresponding to the <up> and <down> keys). This is
potentially destructive, as what these <up> and <down> keys do depend
on the application.

Hi,

You can disable this behavior with:

  printf '\e[?1007l'

See "Alternate Scroll Mode" at
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html .

You're right, I can't argue with this. Many times it's pretty
convenient though, e.g. inside "less".


cheers,
egmont

Hi,

Thanks for the information. I'm wondering why this isn't documented
in the GNOME Terminal help.

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. The user could also configure the shell prompt
(or similar) to disable it in case of SIGKILL (just like other
terminal modes that could be changed by various applications).

Hi,

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. (Even if we did so, a wiki page
or something similar would probably be a better platform; rather than
the help pages which are expected to get translated to a plethora of
languages.)

That approach would have pros and cons, too. For example, it would
need to have explicit support from every application; it would only
work in those few that actually care enough to implement emitting
these sequences. Currently it works everywhere.

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.

I can't really imagine an app that doesn't care enough about scrolling
to add mouse handling, but would care enough to add support for this
1007 "fake scrolling".

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

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.


cheers,
egmont

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

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

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.

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

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.

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.

Hi,

No, not at all. At least I get this behavior in xterm and konsole, too.

Just as much as you can disable now, by writing wrapper scripts. Or
just a one-off disabling in your shell startup files.

It's unclear to me who would go through apps and decide which ones to
turn on this feature, and how it would actually be implemented, e.g.
would some distributions ship wrappers by default to hundreds of apps
where scrolling is potentially useful? Because if it's up for
individual users to come up with wrapper scripts for themselves to
enable, it would probably be used by so few people that it would not
be worth it to have this feature at all.

Which means "less" will enable mouse reporting, that is, you will no
longer get synthesized keypresses for scrolling.

That's your opinion on a design dilemma with IMO no clear single answer.

I recalled it incorrectly, then. (I'm still not sure, there was quite
some confusion, maybe the feature appeared in gnome-terminal without a
way to turn it off, and the escape sequence was then introduced by
xterm? I can't remember. Whatever.)

I've seen a lot of people looking for mouse wheel support in "less" on
various forums, having seen it already e.g. in gnome-terminal,
wondering where it disappeared. I didn't see people complaining about
the existence of this feature, apart from you.


cheers,
egmont

I don't get it in xterm, rxvt and mlterm.

Yes, but my point is that the default should not be broken.
Currently, it is broken in Mutt, and in "less", it is partly
broken (when one starts to type text for a search, the wheel
has an effect on the history instead of scrolling text, and
even if one wants to apply the wheel to the history, it is
currently meaningless as entries are skipped).

In any case, it should be fixed.

Hi,

One could argue that the wheels working in "less" (or any other
similar app) is the expected behavior, and not working at all is the
broken one...

I think we just have to agree that we disagree.


cheers,
egmont

No, that's just a feature. And what gnome-terminal does is buggy
in "less", and completely broken in Mutt and in GNU Screen + bash
(this can even freeze Screen, which doesn't seem to be able to
handle so many events at once!). What gnome-terminal assumes is
that <up> and <down> does scrolling. This may be the case with
some applications (possibly under some context only), but these
keys may also do something completely different. Thus this is a
wrong assumption.

Perhaps it should have generated scroll-backward (kR) and
scroll-forward (kF) keys, and provided a terminfo that defines
them. That way, this wouldn't mix up with the <up> and <down>
keys.

Hi,
to handle kR and kF, it could just as easily handle mouse scroll
events directly.

Again, the point of this feature, which you disagree with, was to make
it _automatic_ (even despite its drawbacks in some contexts) for apps
that don't care enough.

(And, on a totally irrelevant note, which has been discussed many
times and I won't start over, gnome-terminal doesn't ship its separate
terminfo but piggybacks xterm's.)

While the feature isn't perfect (it cannot be due to its nature), it's
arguably still more useful for many people than harmful. I've seen
many more people complaining about its lack whenever it didn't work
for them, than complaining about its problems and imperfectness. If
you find it harmful, you can switch it off.


cheers,
egmont

No, because handling mouse scroll events needs special support in
the application, while handling kR and kF just needs a small change
of configuration (basically, adding a key binding).
downstream to change the default configuration. This is easy to do,
and all users would benefit from this change, with no drawbacks.

That is its own problem. But note that the xterm-based terminfo data
could also add such keys.

This has no effect when using GNU Screen. For instance:

$ printf '\e[?1007l' ; screen sleep 20

then when using the mouse wheel:

^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A

There isn't such an issue with xterm. It is not Screen that enables
Alternate Scroll Mode, otherwise one would get the same behavior in
xterm.

I suspect that GNOME Terminal "forgets" this setting under some
conditions.

Moreover, it is not possible to use "printf '\e[?1007l'" easily when
using "--" + some arbitrary command (whose arguments may contain
spaces and other special characters, so that using "sh -c ..." to
execute the printf first would be complex and error prone).

a virtual terminal), as I can reproduce the same issue after a
"tput reset". Thus "printf '\e[?1007l'" is not sufficient. Actually,
a reset should not have an effect on the Alternate Scroll Mode, as
in xterm, it doesn't as shown by:

$ printf '\e[?1007l'
$ screen sleep 20
$ printf '\e[?1007h'
$ screen sleep 20

and using the mouse wheel in Screen for both instances (after the
printf '\e[?1007h', the Alternate Scroll Mode remains enabled while
the default is disabled in xterm).

Note: Executing "printf '\e[?1007l'" inside screen as a workaround is
incorrect as there is no way to know whether the parent terminal will
accept this sequence or will behave in a strange manner. Moreover,
this is not possible when "screen" is followed by a command.

FYI, a version of "less" with mouse support is now in Debian/unstable.

Hi!

Thanks for the update!

Unfortunately, using this option results either in a much slower
scroll, or if "--wheel-lines=n" is specified then a more rough
scrolling experience than the synthesized up/down keypresses generated
from a touchpad.

This is due to the limitation of mouse protocol, see the first bullet
point at https://bugzilla.gnome.org/show_bug.cgi?id=755183. Terminal
developers should introduce an extension to overcome this limitation,
which then "less" could also implement.

On the other hand, the new "--mouse" option of "less" certainly has
advantages too, e.g. only jumping back by one entry in the search
field, even when "--wheel-lines=n" is specified; this, as discussed in
this bug, can't be automatically "fixed" when the terminal emulator
synthesizes keypresses from a mouse wheel.

Based on these, users can pick their favorite mode of operation.

e.

But there's still no way to disable the general mouse behavior,
e.g. when using GNU Screen.

I don't intent do revive that discussion where we disagreed. We
probably still disagree on those things the exact same way, and still
nothing changed on VTE's side.

As for less's mouse support, you might want to be aware of
https://github.com/gwsw/less/issues/24 (tl;dr: it's broken).

What I'm just asking is that this should be configurable.

Currently, gnome-terminal is unusable for me.

Summary of the issue: VTE took the mouse wheel scrolling feature in
alternate screen from xterm. So one expects it to behave like xterm
(possibly except for the default behavior). With xterm, a terminal
reset (e.g. with the "reset" command) preserves this setting (just
like a reset will preserve the terminal size and other UI settings,
as opposed to content-related settings). But with VTE-based terminals
like GNOME Terminal and xfce4-terminal, the mouse wheel behavior is
reset to the hardcoded default. This can be tested with:

  printf '\e[?1007h' ; reset ; less some_file
  printf '\e[?1007l' ; reset ; less some_file

in the chosen terminal.

One consequence is that with GNU Screen, it is impossible to choose
the mouse wheel behavior when the real terminal is based on VTE
(see below), while the generated key up / key down events may be
destructive in some applications.

In fact, \e[?1007l and \e[?1007h inside a GNU Screen window are
ignored. So
  * With xterm, GNU Screen uses the current setting of xterm.
    For instance, one can choose it in a limited way with
      printf '\e[?1007h' ; screen -r
      printf '\e[?1007l' ; screen -r
  * But with VTE-based terminals, this is reset to the default,
    i.e. mouse wheel events always send key up / key down escape
    sequences, and there doesn't seem to be anyway to change it.