fix: clip mouse selection copy to pane#327
Conversation
Use the originating pane rect when extracting mouse selections so multi-line clipboard copies cannot include neighboring panes. Add coverage for reading-order and block selections that cross split boundaries.
23a02f1 to
f18f73e
Compare
|
Nice catch @burakkose, and solid implementation. Verified this against tmux's behavior. In tmux, each pane operates on its own backing screen (sized to the pane, not the terminal), so multi line selections naturally stay within pane boundaries. psmux was doing the overlay clipping correctly (the visual highlight was confined to the pane) but the actual text extraction for clipboard was reading the full terminal width on intermediate rows. Your approach of threading the originating pane rect into �xtract_selection_text and intersecting each row with that rect is clean and correct. The selection_row_cols helper is well structured. Tests cover both reading order and block mode across a split boundary, which is exactly what was needed. All 2030 existing unit tests pass with zero regressions. Merged. Thanks for the contribution! |
Summary
Fixes
pwsh-mouse-selectionclipboard extraction so multi-line mouse selections are clipped to the originating pane, matching the visible selection overlay.Previously, the overlay was pane-clipped but
Ctrl+C,Ctrl+Shift+C, right-click copy, and legacy copy-on-release could still extract full terminal-width intermediate rows, which could include text from neighboring panes.Related to #211
Approach
Tests
cargo test -q extract_selection_text