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

Introduce mouse release and mouse drag events #2606

Merged
merged 4 commits into from
Mar 14, 2024

Conversation

dmaluka
Copy link
Collaborator

@dmaluka dmaluka commented Oct 25, 2022

Introduce separate mouse release and mouse drag (move while pressed) events: MouseLeftRelease, MouseLeftDrag, MouseRightRelease etc, to allow binding them to actions independently from mouse press events (MouseLeft, MouseRight etc).

This PR:

  • Makes it possible to handle mouse release and drag for arbitrary mouse events and actions (including Lua actions), not just for MouseLeft event and its default MousePress action as in the current code.

  • Fixes issue PastePrimary triggers on every cursor movement while MouseMiddle is pressed #2599 with PastePrimary and MouseMultiCursor actions: selection is pasted not only when pressing MouseMiddle but also when moving mouse with MouseMiddle pressed; similarly, a new multicursor is added not only when pressing Ctrl-MouseLeft but also when moving mouse with Ctrl-MouseLeft pressed.

My initial approach was not to introduce new events for mouse release and mouse drag but to pass "mouse released" info to action functions in addition to *tcell.EventMouse to let the action functions do the necessary checks (similarly to what MousePress is already doing). But then I realized it was a bad idea, since we still want to be able also to bind mouse events to regular key actions (such as PastePrimary) which don't care about mouse event info.

Fixes #1791 (together with PR #2605)
Fixes #2599

@zyedidia
Copy link
Owner

zyedidia commented Nov 2, 2022

Thanks for this (and #2605). I'll try to take a look shortly.

@dmaluka
Copy link
Collaborator Author

dmaluka commented Nov 5, 2022

Thanks for this (and #2605). I'll try to take a look shortly.

Cool, thanks. In the meantime I've added one more commit 37fc558 which fixes another bug with mouse release which I've just found (this bug exists without my PR as well).

Introduce separate mouse release and mouse drag (move while pressed)
events: MouseLeftRelease, MouseLeftDrag, MouseRightRelease etc,
to allow binding them to actions independently from mouse press events
(MouseLeft, MouseRight etc).

This change:

- Makes it possible to handle mouse release and drag for arbitrary mouse
  events and actions (including Lua actions), not just for MouseLeft as
  in the current code.

- Fixes issue zyedidia#2599 with PastePrimary and MouseMultiCursor actions:
  selection is pasted not only when pressing MouseMiddle but also when
  moving mouse with MouseMiddle pressed; similarly, a new multicursor is
  added not only when pressing Ctrl-MouseLeft but also when moving mouse
  with Ctrl-MouseLeft pressed.

My initial approach was not to introduce new events for mouse release
and mouse drag but to pass "mouse released" info to action functions
in addition to *tcell.EventMouse to let the action functions do the
necessary checks (similarly to what MousePress is already doing). But
then I realized it was a bad idea, since we still want to be able also
to bind mouse events to regular key actions (such as PastePrimary)
which don't care about mouse event info.
If we press mouse, drag and then release, the release event is
generated twice, since both mouse press and mouse drag events have been
saved in mousePressed map. To fix that, ensure that we only store mouse
press events in it.
When we temporarily disable the screen (e.g. during TermMessage or
RunInteractiveShell), if the mouse is pressed when the screen is still
active and then released when the screen is already stopped, we aren't
able to catch this mouse release event, so we erroneously think that the
mouse is still pressed after the screen is restarted. This results in
wrong behavior due to a mouse press event treated as a mouse move event,
e.g. upon the left button click we see an unexpected text selection.

So need to reset the mouse release state to "released" after restarting
the screen, assuming it is always released when the screen is restarted.
Since now bufpane handles mouse move and release events generically and
separately from mouse press events, that creates a mess when we dispatch
a mouse press event to an inactive pane without making it active.

For example:
1. Click the right button on an inactive pane. It remains inactive.
2. Then click the left button on it. It becomes active, and an
unexpected text selection appears.
The reason is that the release event for the first click was dispatched
to a wrong pane - the (then) active one, so the (then) inactive pane
didn't get the release event and treats the second click not as a mouse
press but as a mouse move.

The simplest way to fix it is to avoid this scenario entirely, i.e.
always activate the pane when clicking any mouse button on it, not just
the left button.

For mouse wheel motion events we keep the existing behavior: the pane
gets the event but doesn't become active. Mouse wheel motion events are
not affected by the described issue, as they have no paired "release"
events.
@dmaluka dmaluka force-pushed the mouse-release-and-drag-events branch from 5d8642e to 2d95064 Compare January 29, 2023 17:41
@dmaluka dmaluka merged commit 00174bb into zyedidia:master Mar 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants