Summary

• Wheel-up now correctly enters copy mode in 0.4.4.
• Drag-select from normal mode still uses terminal-native selection and does not enter copy mode.
• While selecting in copy mode, moving cursor to pane top edge does not auto-scroll up/extend selection.
• Clicking another pane while in copy mode causes copy-mode behavior to become global again across panes.

Environment

• OS: Windows 11
• Terminal: Windows Terminal
• Shell: PowerShell 7
• psmux: 0.4.5
• tmux (parity reference): 3.6a (no user config, mouse enabled)
• Config state for verification: reproduced with default config for psmux

Note (keyboard selection status)

• The prior keyboard default-selection issue appears fixed in 0.4.3:
  • copy-mode selection defaults to linear (stream), not rectangular.
• Rectangular selection capability appears present, but the tmux-style toggle entrypoint is missing.
• Remaining keyboard parity gap:
  • v does not toggle rectangular selection, but cancels selection.
  • rectangle-toggle is not exposed in list-keys or list-commands.

Expected

• Mouse selection for tmux parity:
  • With mouse off, terminal-native selection behavior is expected (not pane-local, terminal selection highlight).
  • In tmux 3.6a parity testing with mouse on, observed behavior is:
    • mouse click-and-drag from normal mode enters copy mode and starts pane-local selection
    • while dragging, moving to the top edge of a pane scrolls up and extends selection upward
    • selection highlight is copy-mode highlight (not terminal-native highlight)
    • on mouse button release, selection is copied, copy mode exits, and pane returns to normal mode

Actual

• Mouse selection:
  • In normal mode, mouse selection behavior appears identical to mouse off:
    • selection is not pane-local
    • highlight remains terminal-native selection highlight
    • drag/release does not appear to switch through copy mode semantics
  • In copy mode, mouse selection behavior appears mostly aligned with tmux semantics except:
    • moving mouse cursor to top of pane does not cause screen to scroll
    • switching panes using mouse click causes global copy mode behavior again (possible regression of Copy mode is not pane-local across panes/windows #43).
    • after yank operation does not automatically return to normal mode.

Reproduction

1. Start a fresh attached psmux 0.4.5 session (default config) and create split panes.
2. Generate enough lines in a pane to allow scrolling (for example hold Enter).
3. Set mouse on, confirm state:
   • psmux set -g mouse on
   • psmux show -gv mouse
4. From normal mode, drag-select across a pane boundary and observe behavior.
5. Enter copy mode, then drag-select and move cursor to pane top edge; observe whether selection auto-scroll-extends.
6. While still in copy mode, click a different pane and observe whether copy mode stays pane-local or becomes global.

Supplemental keyboard note repro (non-blocking for this mouse issue)

7. Enter copy mode (Ctrl+b [), start selection (Space), move with h/j/k/l, and verify selection is linear by default.
8. Press v while still in copy mode and observe no rectangle-toggle effect.
9. Run psmux list-keys | Select-String -Pattern "rectangle-toggle" and observe no output.
10. Run psmux list-commands | Select-String -Pattern "rectangle-toggle" and observe no output.

Result

Primary divergences in 0.4.5 are normal-mode drag parity, missing copy-mode top-edge auto-scroll extension, and copy-mode scope switching behavior across panes.