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 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.
I think that the cause is that Screen does a reset (since it starts 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. -- Vincent Lefèvre <vinc...@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)