Introduce mouse release and mouse drag events #2606
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Owner
|
Thanks for this (and #2605). I'll try to take a look shortly. |
Collaborator
Author
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
force-pushed
the
mouse-release-and-drag-events
branch
from
5d8642e to
2d95064
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce separate mouse release and mouse drag (move while pressed) events:
MouseLeftRelease,MouseLeftDrag,MouseRightReleaseetc, 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