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

Control: reassign -1 libvte-2.91-0 0.68.0-1 Control: retitle -1 libvte-2.91-0: mouse wheel scrolling setting XTERM_ALTBUF_SCROLL is not preserved by a screen reset Summary of the issue: VTE took the mouse wheel scrolling feature in alternate screen from xterm. So one expects it to behave like

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

On 2019-09-18 11:37:10 +0200, Egmont Koblinger wrote: > 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. What I'm just asking is that this should be configurable. Currently,

Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate 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). On Wed, Sep

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

On 2019-09-18 10:29:12 +0200, Egmont Koblinger wrote: > Based on these, users can pick their favorite mode of operation. But there's still no way to disable the general mouse behavior, e.g. when using GNU Screen. -- Vincent Lefèvre - Web: 100% accessible validated

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

Hi! > FYI, a version of "less" with mouse support is now in Debian/unstable. 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

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

On 2019-02-07 13:43:20 +0100, Egmont Koblinger wrote: > You're right, I can't argue with this. Many times it's pretty > convenient though, e.g. inside "less". FYI, a version of "less" with mouse support is now in Debian/unstable. -- Vincent Lefèvre - Web: 100%

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

On 2019-04-03 13:42:50 +0200, Vincent Lefevre wrote: > On 2019-02-07 13:43:20 +0100, Egmont Koblinger wrote: > > You can disable this behavior with: > > > > printf '\e[?1007l' > > This has no effect when using GNU Screen. For instance: > > $ printf '\e[?1007l' ; screen sleep 20 > > then when

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

On 2019-02-07 13:43:20 +0100, Egmont Koblinger wrote: > You can disable this behavior with: > > printf '\e[?1007l' This has no effect when using GNU Screen. For instance: $ printf '\e[?1007l' ; screen sleep 20 then when using the mouse wheel:

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

On 2019-02-08 15:21:00 +0100, Egmont Koblinger wrote: > > 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 and > > keys. > > There would be no point in that either: if

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

Hi, > 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 and > keys. There would be no point in that either: if an application cares enough to handle kR and kF, it could just

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

On 2019-02-08 14:02:14 +0100, Egmont Koblinger wrote: > > Yes, but my point is that the default should not be broken. > > 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... No, that's just a

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

Hi, > Yes, but my point is that the default should not be broken. 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

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

On 2019-02-08 02:14:45 +0100, Egmont Koblinger wrote: > > But this one is really special as specific to GNOME Terminal. > > No, not at all. At least I get this behavior in xterm and konsole, too. I don't get it in xterm, rxvt and mlterm. > > Well, for applications that do not have any support,

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

Hi, > But this one is really special as specific to GNOME Terminal. No, not at all. At least I get this behavior in xterm and konsole, too. > 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

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

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

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

Hi, > 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. (Even if we did so, a wiki page or

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

Hi, On 2019-02-07 13:43:20 +0100, Egmont Koblinger wrote: > You can disable this behavior with: > > printf '\e[?1007l' > > See "Alternate Scroll Mode" at > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html . Thanks for the information. I'm wondering why this isn't documented in the

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

Hi, You can disable this behavior with: printf '\e[?1007l' See "Alternate Scroll Mode" at https://invisible-island.net/xterm/ctlseqs/ctlseqs.html . > This is potentially destructive, as what these and keys do depend > on the application. You're right, I can't argue with this. Many times

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

Package: gnome-terminal Version: 3.30.2-2 Severity: normal 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 and keys). This is