Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mouse scroll events and mouse copying requiring [Shift] #2196

Open
BarbzYHOOL opened this issue Nov 28, 2023 · 2 comments
Open

Mouse scroll events and mouse copying requiring [Shift] #2196

BarbzYHOOL opened this issue Nov 28, 2023 · 2 comments

Comments

@BarbzYHOOL
Copy link

shift works for Tilix

yes but why do we need shift and not just click??

Maybe you should ask the Tilix authors? They could probably shed further light on this.

Basically moar tells the terminal it wants mouse scroll events, and in most terminals (like Tilix), this has the side effect of disabling mouse copying.

Don't know why a lot of terminals disable mouse copying when reporting scroll events. In iTerm this is configurable so that you can copy without holding down any special button.

Comparing to less, less defaults to broken mouse scrolling but working copying. moar defaults to working mouse scrolling but broken copying.

Originally posted by @walles in walles/moar#53 (comment)

@egmontkob
Copy link

An application can request to receive mouse events: both clicks and scrolls. There's no protocol to request only one kind.

If an application enables this mode, both click and scroll events have to be explicitly sent to that app. That is, in order to revert to their traiditional operation (selecting text), a modifier needs to be pressed.

An application cannot request scroll events to be delivered but click events to be handled by the terminal for copy-pasting.

That being said, there's a special mode called "alternate screen scrolling". This is enabled in Tilix (VTE) by default. What it does is: For apps that do not request mouse event, but do switch to the so-called "alternate screen" (where there's no scrollback buffer, so mouse scroll events would do nothing), the terminal converts mouse scroll events to up/down keypresses. Your app sees the same as if you pressed the up or down arrow, and doesn't have a clue that it was initiated from a mouse wheel instead. While it works as expected in many cases, obviously there are many other cases where this can go wrong.

This feature was designed as a workaround for non-mouse-aware apps. Apps that wish to receive mouse events aren't supposed to rely on this mode, they are supposed to explicitly enable mouse support. And, yes, then you have to press Shift to highlight text in the terminal, that's the nature of the game.

@BarbzYHOOL
Copy link
Author

ok thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants