[idea] Triple-click to select and copy full logical line

[guilhermecvm]

idea / problem

Double-click copies a word (PR #296), but there's no quick way to select an entire line with the mouse. In iTerm2, Ghostty, and other terminals, triple-click selects the full logical line (joining soft-wrapped rows). Herdr doesn't have this, you have to drag carefully across the whole line.

requested change

Triple-click in a pane should select and copy the full logical line, including across soft-wrapped visual rows. Trailing whitespace trimmed, highlight spans all rows of the logical line. Mouse reporting panes unaffected.

why you want this

I triple-click constantly to grab commands, paths, and log lines. It's muscle memory from every terminal I've used. Without it I have to drag precisely or switch to copy mode for something that should be instant.

I also have a working implementation and am using it locally already.

[coreyhines]

+1 from Ghostty on macOS (Herdr 0.7.1)

Double-click word/token copy in panes works well for me. Triple-click line select is the gap I notice most when switching from plain Ghostty.

In Ghostty without Herdr, triple-click selects the full logical line. Inside Herdr, triple-click does not select a pane line the same way. Copy mode (prefix+[ → V → y) is pane-scoped and works, but it is slower than the mouse gesture I use constantly for commands, paths, and log lines.

I also tried the terminal bypass path (Shift + triple-click). Ghostty then selects at the full terminal row level, which includes the sidebar and other columns on that row—not just the focused pane. So that workaround does not match native terminal behavior for me.

Would love pane-local triple-click to mirror double-click: select and copy the full logical line within the focused pane, including soft-wrapped rows, without affecting mouse-reporting apps.

[adamshand]

Yes please! I really miss triple click.

[nahyeongjin1]

+1, and one design detail I think this idea should nail down before someone implements it.

Environment: herdr 0.8.0, macOS 26.3.1, host terminal Ghostty.

Confirming the gap is real in 0.8.0. I went looking through the shipped binary for a triple-click path before filing anything of my own. There are exactly two mouse selection primitives in there:

copied double-clicked token to clipboard
copied selection to clipboard

No triple-click, line-selection, or click-count strings anywhere. The [ui] config template documents the same two and only those two:

copy_on_select — Automatically copy text selected with the mouse.
Set false to retain drag or double-click word selection until Ctrl+C, or Cmd+C when the host forwards it, copies and clears it.

The design detail: triple-click should be copy_on_select-aware, not "select and copy".

The title and body here both say "select and copy". If it lands that way it will be the only mouse gesture in herdr that ignores copy_on_select. Users who set copy_on_select = false (see #993, #710) did so precisely because they want the selection to sit there until they press Ctrl+C — and they'd reasonably expect the new gesture to obey the same switch:

• copy_on_select = true (default) → triple-click selects the logical line and copies it, with the ~500ms highlight, matching double-click today.
• copy_on_select = false → triple-click selects the logical line and leaves it selected; Ctrl+C (or Cmd+C when the host forwards it) copies and clears, same as drag and double-click do now.

Concretely, that means the copy_on_select doc line becomes "drag, double-click word, or triple-click line selection", and triple-click reuses whatever code path double-click already goes through rather than calling the clipboard directly.

Everything else in the original request I agree with as written: logical line across soft-wrapped rows (#922), trailing whitespace trimmed, pane-local so mouse-reporting apps are unaffected, highlight spanning all rows of the logical line.

On the Shift+triple-click bypass another commenter mentioned — same result here on Ghostty. The host selects the full terminal row, so you get the sidebar and the neighbouring split glued onto every line. It isn't a workaround, it's a different feature. Copy mode works but it's four keystrokes for something that should be one gesture.

@guilhermecvm you mentioned you have a working implementation locally — does it route through the existing copy_on_select handling, or does it copy unconditionally?