[idea] Support OSC 52 paste

[oskarkook]

idea / problem

OSC 52 paste doesn't currently work inside herdr.

requested change

Support OSC 52 paste inside herdr.

why you want this

I use OSC 52 paste.

[robsonpeixoto]

I like some of the ideas from Ghostty's solution: https://ghostty.org/docs/config/reference#clipboard-read

• clipboard-read defaults to ask
• clipboard-write defaults to allow

The possible values are ask, deny, and allow.

Unfortunately, setting it to deny causes Vim to freeze. To avoid this, perhaps herdr could add a blank value that always returns an empty value.

Today, I'm using the following workaround to avoid the freezing:

vim.opt.clipboard = "unnamedplus"
if vim.env.HERDR_ENV == "1" then
  local osc52 = require("vim.ui.clipboard.osc52")
  local function internal()
    return { vim.fn.getreg('"', 1, true), vim.fn.getregtype('"') }
  end
  vim.g.clipboard = {
    name = "osc52-copy-only",
    copy = {
      ["+"] = osc52.copy("+"),
      ["*"] = osc52.copy("*"),
    },
    paste = {
      ["+"] = internal,
      ["*"] = internal,
    },
  }
elseif vim.env.SSH_CONNECTION then
  vim.g.clipboard = "osc52"
end

[robsonpeixoto]

Thanks @nimser, I updated the example with your suggestion.

[nimser]

Dug into why this hangs. herdr just doesn't answer OSC 52 read queries, it never wires up the clipboard-read side of libghostty, so the query gets no reply at all. Neovim waits 1s, prints "Waiting for OSC 52 response...", waits 9 more, then gives up. With clipboard=unnamedplus that's 10s on every plain p.

@robsonpeixoto's blank idea might be cheap: libghostty can reply "denied", which answers OSC 52 with an empty clipboard. Neovim takes the empty answer and returns instantly. No read routing or consent policy needed, ask/allow could come later.

Also, that no_paste returning 0 loses the register type, so linewise yanks paste charwise. { vim.fn.getreg('"', 1, true), vim.fn.getregtype('"') } keeps p normal.

[gou4shi1]

+1 — I hit this in local sessions too, not only over herdr --remote. Verified on stable 0.9.5: a pane program that emits ESC]52;c;? gets no reply within 3s, and running the TUI under a PTY that does answer OSC 52 read queries shows herdr never forwards the query to the outer terminal. So with Neovim's osc52 provider, every paste waits out the 10s timeout on a plain local run.

On the design question above: the full version doesn't necessarily need herdr to invent its own ask/allow/deny policy. While a client is attached, herdr can forward the pane's read query to the outer terminal and route that terminal's answer back. The outer terminal's own clipboard policy (Ghostty's clipboard-read = ask, iTerm2's prompts, kitty's clipboard_control) stays the consent gate; a terminal that refuses or ignores the query leaves the program unanswered, same as if the program ran there directly. nimser's empty/denied auto-reply still seems right as the fallback when no attached client can answer, so programs fail fast instead of hanging for 10s.

I've implemented the forwarding version on my fork (local sessions, BEL/ST terminators, reply written back only to the querying pane): gou4shi1@1688b8a — happy to contribute it or rework it against whatever shape maintainers prefer.