Feature request: Getting text out of the diff view — mouse selection is swallowed by mouse support

[denysshnurenko]

I often want to copy a bit of what I'm reading in revdiff — a line of code, an error string, a symbol name — into a chat, a terminal, or a search box. Right now I can't find a way to do it without giving something up.

Mouse support (scroll wheel, click) means the terminal never sees the drag, so native select + copy does nothing. --no-mouse gives selection back, but then scrolling and click-to-navigate are gone — it's all-or-nothing, and I want scrolling far more often than I want to copy, so in practice I just don't copy.

I couldn't find an existing request for this. #138 proposed yy as part of vim chords and was closed; the open question there was yank scope (raw line with +/- vs clean content vs the full rendered row). This is a narrower ask — not which slice to yank, but having any path to the system clipboard while mouse navigation stays on.

Some directions, in rough order of how cheap they look from outside:

1. Document the terminal-level override, if there already is one. Many terminals bypass mouse reporting while a modifier is held (shift+drag). If that's the intended answer it just needs a line in the docs — and this can be closed.
2. A key to suspend mouse capture for the next selection, or a toggle, so --no-mouse doesn't have to be a launch-time decision.
3. A copy action bound to a key — the Vim-style line movements #138 route, with the scope questions that come with it.

(1) would fully solve it for me.

Environment: revdiff v1.11.1, macOS 15.7.2, running in an agterm overlay (ghostty-based).

[umputun]

(1) is the answer, and it was already in the docs, just not in a form that would have found you. The list named kitty, iTerm2 and "most other terminals", and never said ghostty. Fixed in 170263a, which spells out ghostty/agterm and adds the two points below.

shift+drag does work in an agterm overlay. Agterm is libghostty underneath and doesn't override the default, and ghostty's mouse-shift-capture defaults to false, which means shift is deliberately not forwarded to the application so the terminal keeps it for selection. Nothing on revdiff's side can defeat that either, bubbletea never emits XTSHIFTESCAPE.

the likely reason it looked dead: ghostty also uses shift to extend an existing selection. If anything is already selected, shift+drag grows that selection instead of starting a new one, which reads exactly like selection doing nothing. Clear it first, then drag.

your (2) also already exists, one layer down. Ghostty 1.3.0+ has a toggle_mouse_reporting keybind that suspends mouse capture at the terminal, unbound by default. Bind it in your ghostty config and you get the runtime switch without the launch-time decision.

I don't want an in-app version of that. Once mouse reporting is on, the terminal hands drags to the application, that's the protocol and not something revdiff can opt out of while keeping wheel and click. The shift override and the terminal's own toggle already cover it, so a third way from revdiff would just be another key to document.

(3) stays where #147 left it. yy was left out on purpose because clipboard plus OSC-52/ssh fallback is its own design problem, and a separate ticket answering the yank-scope questions is still welcome.