I don't know if this is useful to consider but this is what I have in my config (ref):

local function osc52_copy(text)
  local text_b64 = encode_base64(text)
  local osc = string.format('%s]52;c;%s%s', string.char(0x1b), text_b64, string.char(0x07))
  io.stderr:write(osc)
end

vim.api.nvim_create_autocmd('TextYankPost', {
  callback = function()
    osc52_copy(vim.fn.getreg(vim.v.event.regname))
  end
})

Which allows osc52 copy to work on top of g:clipboard and so copy/paste within nvim to work normally.

I ditched the g:osc52 variable and instead exposed this via a vim.clipboard.osc52 module that must be required. I think this is a better solution as it is more flexible (users can choose whether or not to use OSC 52 for pasting) and perhaps plugins might be able to make use of it?

EDIT: Exposing the module also allows users to do what @lewis6991's snippet does (e.g. copy via OSC 52 in a TextYankPost autocommand).

I implemented pasting via OSC 52 as well, so this fully resolves #3344. Pasting depends on #25868 so that PR has to be merged first.

This is opt-in as not all terminal emulators support OSC 52

#3344 mentions:

They're also really easy to probe for and ask if it's supported, so you can fall back on some other mechanism if they're not

Can we enable by default if the terminal response indicates that OSC 52 is supported?

I'm not aware of any mechanism to query for OSC 52 support, without actually querying the clipboard itself. But this would be extremely annoying because many terminals prompt the user when an application tries to read from the clipboard, so if we queried for support by just trying to read and checking for a response the user would be prompted every time Nvim started up.

But this would be extremely annoying because many terminals prompt the user

We could make it opt-out instead of opt-in if a user config is found?

@gpanders Hi, have you noticed frequent neovim freezes when using osc52?
I've tried on NVIM v0.10.0-dev-1558+gd718a3e27a with LazyVim on kitty 0.30.1/alacritty 0.12.3 (5efb0690)
And I'm seeing a lot of 'Waiting for OSC 52 response from the terminal. Press Ctrl-C to interrupt...'.
Copying and pasteing seems to work across ssh, but those freezes make neovim unusable.

Once Nvim requests the contents of the clipboard with the OSC 52 request there isn't anything we can do until the terminal responds except wait. Do you have a reproducible example where pasting takes a very long time? Are you pasting a lot of data that might take a while to transmit over a slow SSH connection?

The long timeout is intentional because some terminal emulators will prompt the user for permission to read from the system clipboard, so we need to wait long enough for the user to respond in those cases.

@alteriks what does :set clipboard? show? I'm guessing "unnamed"...

this could be link to TMUX, I also notice the new OSC52 clipboard support don't quite work inside tmux because of the extra escape sequence it needs

@justinmk

clipboard=unnamed* is a constant source of issues and serves no purpose (you can opt in to using the clipboard via "+y or a mapping, why do you want x, dd, etc to write to your clipboard?!)

Meanwhile,

• performance workarounds for clipboard=unnamed* tracked in: clipboard: clipboard=unnamed is slow #11804
• if you're going to use clipboard=unnamed* then you cannot possibly expect that to work well over ssh.
• we should add a :checkhealth warning at minimum, and possibly a runtime error.

@gpanders Those freezes are happening on local machine. I'm working on single file and after yanking one line I paste it to same file. After that nvim UI is frozen. After some time I can exit vim using :wq but UI never refreshes.

The long timeout is intentional because some terminal emulators will prompt the user for permission to read from the system clipboard, so we need to wait long enough for the user to respond in those cases.

I've never experienced this using kitty. Currently I'm on wayland. So maybe something doesn't work properly and I'm missing some popup. I'll try later with Xorg.

I've tried creating config to help you reproduce my problem

mkdir ~/.config/nvim_osc52
cat << EOF > ~/.config/nvim_osc52/init.lua
vim.g.clipboard = {
  name = "OSC 52",
  copy = {
    ["+"] = require("vim.clipboard.osc52").copy,
    ["*"] = require("vim.clipboard.osc52").copy,
  },
  paste = {
    ["+"] = require("vim.clipboard.osc52").paste,
    ["*"] = require("vim.clipboard.osc52").paste,
  },
}
EOF

But copying/pasting using this minimal config doesn't work over ssh

clipboard=unnamed* is a constant source of issues and serves no purpose (you can opt in to using the clipboard via "+y or a mapping, why do you want x, dd, etc to write to your clipboard?!)

Meanwhile,

• performance workarounds for clipboard=unnamed* tracked in: clipboard: clipboard=unnamed is slow #11804
• if you're going to use clipboard=unnamed* then you cannot possibly expect that to work well over ssh.
• we should add a :checkhealth warning at minimum, and possibly a runtime error.

For me using clipboard=unnamed* is great feature, because I can yank something from editor and switch to browser and paste it with ctrl+v. I also use pasting with middle mouse click extensively.

With additional mapping I'll have think about it everytime when I'll need to paste some text outside nvim, and most probably I'll have to switch window once again, because I didn't use proper yank

this could be link to TMUX, I also notice the new OSC52 clipboard support don't quite work inside tmux because of the extra escape sequence it needs

Nvim has supported OSC 52 via tmux for a long time. No additional configuration is needed to use OSC 52 in tmux, as long as you are using tmux 3.2 or later.

In fact, we should probably show a warning if the vim.clipboard.osc52() function is called with $TMUX set (maybe we can do this with :checkhealth somehow?)

I've never experienced this using kitty. Currently I'm on wayland. So maybe something doesn't work properly and I'm missing some popup. I'll try later with Xorg.

Asking on paste is the default behavior of kitty: https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.clipboard_control

I cannot reproduce any slowness or delay using kitty (or any other terminal emulator I've tried) on macOS. So maybe this is a Linux specific issue.

In any case, please do not comment on this PR with OSC 52 related issues. To report a bug, please create a new issue with clear reproduction steps.