Add a copy-on-select clipboard target option (PRIMARY selection), matching Ghostty's copy-on-select

[martinholy]

What I'd like

On Linux/X11 and Wayland there are two independent clipboards: the system CLIPBOARD (Ctrl+C / Ctrl+V) and the PRIMARY selection (auto-filled on text selection, pasted with middle-click). Today herdr writes a pane selection to the system clipboard only, so the PRIMARY / middle-click flow doesn't get the selected text.

I'd like a config option that controls which clipboard a pane selection is copied to — modeled directly on Ghostty's copy-on-select.

Prior art: Ghostty's copy-on-select

Ghostty (https://ghostty.org/docs/config/reference#copy-on-select) solves exactly this with one three-valued option. Quoting its semantics so we're matching the real behavior, not my paraphrase:

• false — disables copy on select entirely.
• true — copy on select goes to the selection clipboard (PRIMARY). Not supported on platforms such as macOS. This is Ghostty's default on Linux.
• clipboard — copy on select goes to both the system clipboard and the selection clipboard (on Linux).

Adopting the same option and value names means anyone coming from Ghostty gets the behavior they already expect, and the middle-click flow just works.

Note on default / behavior change

herdr today copies a selection to the system clipboard. Ghostty's true default copies to PRIMARY only. So if herdr matches Ghostty's defaults verbatim, the selection would stop landing on the system clipboard by default — which is a behavior change. A safe alternative is to default herdr to clipboard (both), preserving today's Ctrl+V behavior while adding PRIMARY. I'll defer to your call on the default; flagging it because it's a product-direction decision, not just an implementation detail.

Why this matters to me

Middle-click paste is muscle memory in my Linux workflow. With herdr I select text in a pane but can only paste it via the system-clipboard path, which clobbers whatever I had on Ctrl+C and breaks the select-here / middle-click-there flow I use constantly between terminals and the browser. Matching Ghostty's copy-on-select fixes this.

Rough shape (not a design proposal — open to your direction)

• A copy-on-select-style option accepting false / true / clipboard (exact key/naming/default entirely your call to fit herdr's config conventions).
• On Linux, the PRIMARY write uses the existing tool fallbacks already wired for the clipboard path: wl-copy --primary, xclip -selection primary, xsel --primary.
• macOS/Windows have no PRIMARY concept, so true degrades to / is treated as no selection clipboard there — same constraint Ghostty documents.

I'm aware this touches mouse/selection ergonomics, so I'm raising it as a discussion first rather than a PR. Happy to implement it if it fits herdr's direction — just want a product-direction check and a steer on the config shape, naming, and default before writing anything.

Environment

• OS: Arch Linux (Wayland/X11)
• Affects: Linux (no-op / degraded elsewhere, as in Ghostty)

[ver-1000000]

+1 to this.

I tested a workaround on ArchLinux/Wayland(Hyprland + Ghostty):

wl-paste --type text --watch wl-copy --primary

This makes Herdr's CLIPBOARD copy available as PRIMARY, and middle-click paste works in normal Wayland apps.

However, inside Herdr with ui.mouse_capture = true, bare middle-click is still captured by Herdr and does not paste into the focused pane. Shift+MiddleClick works because it bypasses Herdr and lets the host terminal handle the event.

So I think there are two related pieces:

1. Let copy-on-select target PRIMARY / CLIPBOARD / both, as proposed here
2. When mouse_capture = true, support middle-click paste from PRIMARY into the focused pane on Linux

The second part matters because Herdr's own pane-aware selection is better than terminal-native selection, so mouse_capture = false is not an ideal workaround.

[iui-wang]

+1

[martinholy]

@ogulcancelik I see you've since landed copy_on_select on master (4617456) as a boolean — false disables mouse selection entirely, true (default) keeps copying selections to the system clipboard. That's a better foundation than what I originally proposed here, so I'd like to update this proposal to be a strict extension of your setting rather than a Ghostty-verbatim option.

Updated proposal

Keep ui.copy_on_select and its boolean semantics exactly as they are on master, and additionally accept strings:

Value	Behavior
false / "disabled"	as on master today: mouse selection off entirely
true / "clipboard" (default)	as on master today: copy to the system clipboard
"primary"	copy to the selection clipboard only (PRIMARY on X11/Wayland, middle-click paste)
"both"	copy to both the system clipboard and PRIMARY

What changed vs. my original proposal

• I originally suggested mirroring Ghostty's values verbatim (true = PRIMARY only, "clipboard" = both). That would now silently change behavior for everyone using your setting, since herdr's true already means "system clipboard". So the updated shape keeps every existing config working unchanged and makes the value names self-consistent ("clipboard" ≡ true), at the cost of diverging from Ghostty's naming — I think that's the right trade-off, but flagging it explicitly.
• Defaults don't change at all; PRIMARY is purely opt-in.

Implementation sketch (I have this working locally on top of current master, just check green):

• PRIMARY writes reuse the existing clipboard tool fallbacks (wl-copy --primary, xclip -selection primary, xsel --primary), with an OSC 52 p fallback for SSH/WSL sessions.
• A clipboard-target field rides along the internal ClipboardWrite event and the server→client Clipboard message, so it works in server mode; the current protocol version is already ahead of the latest release, so no extra bump is needed.
• Only automatic on-select copies honor the setting; explicit copies (copy-mode yank, OSC 52 from pane apps) always target the system clipboard.
• macOS/Windows have no PRIMARY, so "both" behaves like true and "primary" selects without copying — same constraint Ghostty documents.
• Docs (docs/next, incl. ja/zh-cn) and the config reference are updated.

I'm happy to open a PR with this if you approve the direction — and equally happy to adjust the value names or shape to whatever fits herdr's conventions.

[martinholy]

Quick update: the proposal above is implemented and up to date on my fork, rebased on current master with just check green:

https://github.com/martinholy/herdr/tree/copy-on-select-primary

Happy to open a PR if the direction gets a go-ahead — and to adjust naming/shape to whatever fits herdr's conventions.

[costis-t]

Wishing it gets traction, it works nicely!