Follow-ups to the drag_or_normal_select selected text drag support:
- Reset the pending drag at the top of handle_button_event again, before
the scrollbar, missing screen and mouse position early returns. Moving
it into a helper placed it after those returns, so a scrollbar track
click (with scrollbar_jump_on_click disabled) no longer cleared an
armed URL drag, letting it fire on a later mouse move with no button
held. Split the helper in two, as arming the drag needs an up to date
mouse position but clearing it does not.
- Clear the click queue for all drag kinds, not just text drags. A native
drag consumes mouse-up, so the press lingered and turned the next press
into a double press, selecting a word instead of starting a new
gesture. Reproducible with link drags before this change.
- Note that handle_potential_drag can call into Python, which can
re-alloc the windows array, so w must not be used after it returns.
Also share the drag thumbnail construction between drag_url and
drag_selection (and skip the thumbnail rather than dividing by zero on a
zero width render), use None instead of -1 for the mock event pixel
position so negative positions remain testable, and tighten the
off-by-one bound in clear_click_queue.
A high resolution wheel delivers one physical detent as several VALUE120
events, so pending_scroll_pixels accumulates fractions of a line and carries
the remainder to the next event. Detents do not reliably total 120 units, so
that carry is load bearing: it is what lets an undersized detent still scroll
a line.
It breaks down when the scroll direction changes, because the residual then
has the wrong sign and the first detent of the new direction is spent
cancelling it rather than scrolling. Measured on a Logitech MX Master 3 under
GNOME/Wayland, against a terminal program that had requested mouse events,
47% of detents that reversed direction scrolled nothing, against 2% of
detents continuing in the same direction.
Discard the residual when the direction changes, and leave the carry alone
otherwise, so scrolling in a single direction is unaffected.
The accumulator state also moves from Screen to OSWindow, since scroll events
are delivered to an OS Window rather than to a particular terminal window.
Add continue_word_upwards_scrollback() and continue_word_downwards_offscreen()
to extend word selection beyond viewport boundaries, mirroring the line
selection fix. Add tests for word selection wrapping into scrollback and
below viewport.
Agent-Logs-Url: https://github.com/kovidgoyal/kitty/sessions/58191e45-d925-4996-b0d5-8b1bd4baa8d5
Co-authored-by: kovidgoyal <1308621+kovidgoyal@users.noreply.github.com>
Similar to commit 625e984 which fixed extending into scrollback (above viewport),
this fix extends line selection below the viewport when a wrapped line continues
past the bottom edge. Adds continue_line_downwards_offscreen() and applies it
in both the initial selection and extending selection code paths.
Agent-Logs-Url: https://github.com/kovidgoyal/kitty/sessions/e548ce84-fdb7-4fd1-b3df-e1166b45f5bd
Co-authored-by: kovidgoyal <1308621+kovidgoyal@users.noreply.github.com>
Follow PEP 0394 and use /usr/bin/env python so that the python in the
users venv is respected. Not that the kitty python files are meant to be
executed standalone anyway, but, whatever.
Fixes#6810
