You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
broken mouse events in fullscreen applications #151
I can't reproduce this. When I use my scroll wheel (actually two finger swipe on a mousepad) it works as I expect. The screen scrolls up. Can you specify what version and OS this is happening on?
When in bash scroll wheel events scroll the terminal buffer, when in less scroll wheel events scroll the less file rather than terminal buffer which is implemented by translating wheel events to arrow keys. While this is not problematic behavior in less it is undesirable in pretty much every other fullscreen application.
Interesting. xterm does nothing with mouse scroll events in less or vim in my Fedora install. The behaviour you're describing seems more like a feature than a bug to me. I suppose we could have an option to enable the behaviour you're looking for.
What xterm does is correct. When the terminal emulator receives scroll event it should scroll. It should not send random events to the terminal application. Doing so is a bug. If there were a transform-scroll-events-to-arrow-keys flag and the application set it if would be fine. However, fullscreen flag is not transform-scroll-events-to-arrow-keys flag so it should not trigger such behavior.
hm, I don't see where this hack is implemented. It seems terminator grew the option to disable mouse zoom since the release but the mouse wheel handler seems to call scroll directly, I see mo translation to keys there. Is it hidden in vte?
Full screen applications run on the alternate screen. The alternate screen does not have scrolling, so the up and down arrow keys are sent to mimic scrolling.
So the question is can we access the normal screens' scrollback when we are on the alternate screen?
When this 'bug' was reported on gnome-terminal, the answer to that question was 'No'. VTE does not provide the normal screen scrollback when on the alternate screen.
I just tried scrolling with less in xterm and I think the way this is implemented in xterm is quite pointless. (as is also pointed out in https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/27) the latest several lines from the normal screen are inaccessible.
Interesting this guy (http://blog.guntram.de/?p=164) has a couple (rather old) patches for vte. It looks like he is disabling switching to the alternate screen for full-screen applications. It's about time for me to turn off my computer for the night. I'll take a closer look at these tomorrow.
However, I think it is safe to say that the way terminator is behaving is the same way all vte based terminals are behaving and per vte, this is the intended behavior.
if (m_screen == &m_alternate_screen &&
m_modes_private.XTERM_ALTBUF_SCROLL()) {
so presumably if XTERM_ALTBUF_SCROLL is unset the bogus key event are not generated and either there is no scrolling or the combined scrolling showing 1st buffer scrollback where it is not covered by the alt buffer.
Given that this behaviour is something that we inherited from the VTE library, we can't really change it in terminator. You could chime in on the vte bug referenced above. I've submitted code to vte and had it accepted before and Egmont is generally a good guy.
There is already code testing for a flag in the VTE library so terminator should be able to clear the flag to change the behavior. There would be reason to report bug against VTE if interface for changing the flag does not work.
However, I do not see any 1007 in my termcap database so this is some non-standard VTE extension that is not even advertised to the application. It may be fine for gnome-terminal to use its own TERM type and advertise this feature but Terminator uses xterm types which do not define it. The it it Terminator's responsibility to set and clear the feature flag.
Activity
mattrose commentedon Jun 30, 2020
I can't reproduce this. When I use my scroll wheel (actually two finger swipe on a mousepad) it works as I expect. The screen scrolls up. Can you specify what version and OS this is happening on?
hramrach commentedon Jun 30, 2020
openSUSE Tumbleweed, terminator 1.92
When in bash scroll wheel events scroll the terminal buffer, when in less scroll wheel events scroll the less file rather than terminal buffer which is implemented by translating wheel events to arrow keys. While this is not problematic behavior in less it is undesirable in pretty much every other fullscreen application.
mattrose commentedon Jun 30, 2020
This behaves exactly the same as other terminal apps out there. In fullscreen or no. I'm not sure what we should be doing instead.
hramrach commentedon Jun 30, 2020
That's not true. In xterm it does not matter if I am running less or bash. Scroll events always scroll terminal buffer.
mattrose commentedon Jun 30, 2020
Interesting. xterm does nothing with mouse scroll events in less or vim in my Fedora install. The behaviour you're describing seems more like a feature than a bug to me. I suppose we could have an option to enable the behaviour you're looking for.
hramrach commentedon Jun 30, 2020
What xterm does is correct. When the terminal emulator receives scroll event it should scroll. It should not send random events to the terminal application. Doing so is a bug. If there were a transform-scroll-events-to-arrow-keys flag and the application set it if would be fine. However, fullscreen flag is not transform-scroll-events-to-arrow-keys flag so it should not trigger such behavior.
hramrach commentedon Jul 6, 2020
hm, I don't see where this hack is implemented. It seems terminator grew the option to disable mouse zoom since the release but the mouse wheel handler seems to call scroll directly, I see mo translation to keys there. Is it hidden in vte?
hramrach commentedon Jul 6, 2020
https://github.com/GNOME/vte/blob/mainline/src/vte.cc#L9395
dugb commentedon Jul 6, 2020
Full screen applications run on the alternate screen. The alternate screen does not have scrolling, so the up and down arrow keys are sent to mimic scrolling.
So the question is can we access the normal screens' scrollback when we are on the alternate screen?
When this 'bug' was reported on gnome-terminal, the answer to that question was 'No'. VTE does not provide the normal screen scrollback when on the alternate screen.
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/27
Still, I think this is worth digging into.
dugb commentedon Jul 6, 2020
I just tried scrolling with
lessin xterm and I think the way this is implemented inxtermis quite pointless. (as is also pointed out in https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/27) the latest several lines from the normal screen are inaccessible.dugb commentedon Jul 6, 2020
Interesting this guy (http://blog.guntram.de/?p=164) has a couple (rather old) patches for vte. It looks like he is disabling switching to the alternate screen for full-screen applications. It's about time for me to turn off my computer for the night. I'll take a closer look at these tomorrow.
However, I think it is safe to say that the way terminator is behaving is the same way all vte based terminals are behaving and per vte, this is the intended behavior.
hramrach commentedon Jul 7, 2020
The condition is
if (m_screen == &m_alternate_screen &&
m_modes_private.XTERM_ALTBUF_SCROLL()) {
so presumably if XTERM_ALTBUF_SCROLL is unset the bogus key event are not generated and either there is no scrolling or the combined scrolling showing 1st buffer scrollback where it is not covered by the alt buffer.
mattrose commentedon Jul 7, 2020
Given that this behaviour is something that we inherited from the VTE library, we can't really change it in terminator. You could chime in on the vte bug referenced above. I've submitted code to vte and had it accepted before and Egmont is generally a good guy.
hramrach commentedon Jul 7, 2020
There is already code testing for a flag in the VTE library so terminator should be able to clear the flag to change the behavior. There would be reason to report bug against VTE if interface for changing the flag does not work.
hramrach commentedon Jul 7, 2020
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/27 show that the feature can be turned off with
echo -ne '\e[?1007l'However, I do not see any 1007 in my termcap database so this is some non-standard VTE extension that is not even advertised to the application. It may be fine for gnome-terminal to use its own TERM type and advertise this feature but Terminator uses xterm types which do not define it. The it it Terminator's responsibility to set and clear the feature flag.
py-terminator: Upgrade to 2.1.0
py-terminator: Upgrade to 2.1.0
py-terminator: Upgrade to 2.1.0
py-terminator: Upgrade to 2.1.0