Add OSC52 plugin for clipboard support

[64-bitman]

I currently am able to test on Windows 11 and Linux, would be nice to have some MacOS testers (using iTerm?)

[habamax]

Could you consider making it optional?

With location in ~/pack/dist/opt/osc52/plugin/... we should be able to enable it with packadd osc52.

[64-bitman]

Could you consider making it optional?

With location in ~/pack/dist/opt/osc52/plugin/... we should be able to enable it with packadd osc52.

Yes I planned on doing that, I'll change it later

[64-bitman]

Could anyone test in MacOS? I have added documentation on how to use

[64-bitman]

I think this is ready. I didn't add tests because this plugin is very simple anyways + I'm not sure how to implement them

[chrisbra]

did someone try it out? Ping @peterwu who requested this functionality in #14995

[peterwu]

I tested on my MacBooks (13.7.8 and 26.0.1) and and found that it works for Ghostty 1.2.2 and kitty 0.43.1 but not the stock Terminal app. (maybe the Terminal app doesn't support OSC52 ? )

In all cases, ommiting g:osc52_force_avail = true results in some escape chars printed on the terminal before vim shows up.

Ghostty prints ^[[?62;22;52c while kitty prints ^[[?62;52c. And when this happens, the OSC52 function does not work.

The following is for my test on Terminal app but the same steps were performed for Ghostty and kitty.

1. compiled from https://github.com/64-bitman/vim/tree/osc52_plugin
2. make
3. make install
4. ~/.vimrc

packadd osc52
set clipmethod^=osc52

This will print ^[[?1;2c when launching vim.
5. ~/.vimrc

packadd osc52
g:osc52_force_avail = true
set clipmethod^=osc52

This doesn't print anything when launching vim.

6. If I do "+yy, the content is not copied to the + register.
7. If I do "*yy, thee content is copied to the * register but not available in the system clipboard.
8. The same happens to "*p as it does not paste what's in the system clipboard to the vim session.

[64-bitman]

In all cases, ommiting g:osc52_force_avail = true results in some escape chars printed on the terminal before vim shows up.

That is likely from Vim trying to detect if the terminal supports OSC 52, I've made it now that is prints a message while waiting for a response, and clears it when it is received. Although some terminals don't support responding to the escape sequence that Vim sends, so Vim just hangs until you press Ctrl-c, don't think there is any way to avoid that.

Ghostty prints ^[[?62;22;52c while kitty prints ^[[?62;52c. And when this happens, the OSC52 function does not work.

Can you elaborate on this? The plugin should match the '52' in those responses and enable the osc52 functionality. Or is it just printing characters to the screen? If so can you try the latest commit?

The following is for my test on Terminal app but the same steps were performed for Ghostty and kitty.

1. compiled from https://github.com/64-bitman/vim/tree/osc52_plugin
2. make
3. make install
4. ~/.vimrc

packadd osc52
set clipmethod^=osc52

This will print ^[[?1;2c when launching vim. 5. ~/.vimrc

packadd osc52
g:osc52_force_avail = true
set clipmethod^=osc52

This doesn't print anything when launching vim.

6. If I do "+yy, the content is not copied to the + register.
7. If I do "*yy, thee content is copied to the * register but not available in the system clipboard.
8. The same happens to "*p as it does not paste what's in the system clipboard to the vim session.

It looks like the default Terminal does not support OSC52 since the DA1 response (to detect OSC52 functionality) is `^[[?1;2c. Could you try iTerm? It looks like it supports OSC 52. Thanks.

[peterwu]

I did a git pull off the osc52_plugin, recompiled and discovered a few things.

If g:osc52_force_avail = true is not set in vimrc, now it prints something like this:

Waiting for OSC 52 response...^[[?64;1;2;4;6;17;18;21;22c

By that, I mean:

1. put the following in vimrc

packadd osc52
set clipmethod^=osc52

2. run vim
3. vim will print these characters right after like this:

$ vim
Waiting for OSC 52 response...^[[?64;1;2;4;6;17;18;21;22c

4. at this time, the vim session seems to wait for ever until I hit ENTER
5. after I hit ENTER, the main vim session shows up but at the bottom it displays a similar message:

~                type  :help version9<Enter>   for version infoWaiting for OSC 52 response...^[[?64;1;2;4;6;17;18;21;22c

that's right: the Waiting message follows directly after the initial startup message
6. at this stage, I can't fire vim commands, such as i, d, y, p, etc. These keys will be printed right after the Waiting message
7. This stops when I hit ENTER again
8. Now, I use the vim session as usual

So, imo, the updated commits made things even worse. Previously, the chars were displayed at step3 but after I hit ENTER, it let me use vim without step 6.

I also tested iTerm2, v3.6.4. If I followed the instructions to enable clipboard access, I can copy content to clipboard but cannot paste content from clipboard. I'm not familar with iTerm2 so maybe I didn't figure out a setting somewhere to enable paste.

[Yamagi]

I gave it a try with Alacritty under Linux and both copy and paste are working fine. Just a small nitpicks: I'm also seeing Waiting for OSC 52 response...^[[?6c. The message added in the last commits makes clear what's going on, but what about adding a hint that the response may never come and pressing Return forces Vim to continue? Also, why do I need press Return four times until Vim starts? :messages is empty.

[alex-huff]

I experience the same issues. However, if I manually run :packadd osc52 and :set clipmethod^=osc52 after vim has already loaded, it works as expected. It seems the primary device attributes event isn't triggered in the context that .vimrc is loaded, causing Available() to hang.

One more thing. When pasting a clipboard that has no newlines, it seems a newline is inserted at the end.