In the interactive TUI, on-screen text cannot be selected with the mouse, so there is no way to copy anything rendered inside the TUI (a provider id, an error message, a resume command, etc.) back out to the clipboard.
Cause
TuiTerminal::new and activate_best_effort in src/cli/tui/terminal.rs run EnableMouseCapture together with EnterAlternateScreen. While mouse capture is active, the terminal emulator routes mouse events to the process instead of performing its native drag-to-select, so selection and copy stop working for the whole TUI session.
The captured events are consumed in exactly one place: src/cli/tui/mod.rs maps MouseEventKind::ScrollUp / ScrollDown to KeyCode::Up / Down. There is no click, drag, or selection handling.
Tradeoff with #342
#342 requests mouse click support, which requires keeping EnableMouseCapture. Under crossterm, mouse capture is all-or-nothing, so terminal-native selection and in-app click hit-testing are mutually exclusive. Filing this to track the copy-paste side of that tradeoff.
Proposal
Drop EnableMouseCapture and the scroll-wheel-to-arrow mapping. The TUI already supports full keyboard navigation (arrows, h/j/k/l, PgUp/PgDn, Home/End), so mouse scroll is a convenience rather than a dependency. If #342 is implemented later, mouse capture should be opt-in (or accept that native selection is lost while active) instead of the default.
The mechanism is terminal-emulator-agnostic: any terminal loses native selection while the app holds mouse capture. Some emulators allow Shift-drag to bypass app capture as a partial workaround, but that is not discoverable and not available everywhere.
In the interactive TUI, on-screen text cannot be selected with the mouse, so there is no way to copy anything rendered inside the TUI (a provider id, an error message, a resume command, etc.) back out to the clipboard.
Cause
TuiTerminal::newandactivate_best_effortinsrc/cli/tui/terminal.rsrunEnableMouseCapturetogether withEnterAlternateScreen. While mouse capture is active, the terminal emulator routes mouse events to the process instead of performing its native drag-to-select, so selection and copy stop working for the whole TUI session.The captured events are consumed in exactly one place:
src/cli/tui/mod.rsmapsMouseEventKind::ScrollUp/ScrollDowntoKeyCode::Up/Down. There is no click, drag, or selection handling.Tradeoff with #342
#342 requests mouse click support, which requires keeping
EnableMouseCapture. Under crossterm, mouse capture is all-or-nothing, so terminal-native selection and in-app click hit-testing are mutually exclusive. Filing this to track the copy-paste side of that tradeoff.Proposal
Drop
EnableMouseCaptureand the scroll-wheel-to-arrow mapping. The TUI already supports full keyboard navigation (arrows,h/j/k/l, PgUp/PgDn, Home/End), so mouse scroll is a convenience rather than a dependency. If #342 is implemented later, mouse capture should be opt-in (or accept that native selection is lost while active) instead of the default.The mechanism is terminal-emulator-agnostic: any terminal loses native selection while the app holds mouse capture. Some emulators allow Shift-drag to bypass app capture as a partial workaround, but that is not discoverable and not available everywhere.