[vim/vim] Feature Request: Clipboard hooks for access to the "* and "+ registers (#7524)

Filipe Brandenburger

unread,

Dec 21, 2020, 11:14:13 PM12/21/20

to vim/vim, Subscribed

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.

Implement hooks to implement access to the "* and "+ registers through code, rather than only support the X11 clipboard/selection.

Adding hooks allow for efficient implementation on platforms that have dedicated utilities (such as pbcopy and pbpaste on MacOS, win32yank.exe on Windows with WSL), also to hook up to third-party tools (such as lemonade), integrate with external window managers (tmux and screen) and also add ability to hook to ad-hoc implementations (e.g. read/write from a specific local file, etc.)

Some of this is possible using mappings, but it's often limited (for example, setting/getting registers directly with setreg() or @* can't be overridden by mappings.) It's also quite hard to get mappings hard in all corner cases. Native direct hook support would be much superior.

Describe the solution you'd like

I think it would be good to implement the same "provider" API used in NeoVim, so that we could use the same or a similar Vimscript implementation.

The API tries to autoload a provider#clipboard#Call function and use it to call methods (get and set) through that function. It also uses a global variable g:loaded_clipboard_provider which needs to be set to indicate that the provider is implemented.

Implementing a compatible API would be beneficial to plug-in writers who are interested in creating alternative implementations for this provider, since the implementation would work in both Vim and NeoVim.

Describe alternatives you've considered

Mappings are sometimes possible (e.g. nnoremap "*y etc.) but it's really messy to always get this right.

I took inspiration in the NeoVim API, but if that's not workable for Vim, an implementation using a different API would be acceptable, since the core need is what I care about and in most cases it's possible to have a small shim that bridges both APIs, while sharing a lot of the underlying code (for auto-detecting clipboard tools, etc.)

Additional context

I embarked on this journey to implement the clipboard provider in Vim.

I have a Work-in-Progress commit that you can take a looks at. It implements the +provider feature as a generic feature, even though "clipboard" is the only available provider. (This API is the same as the one in NeoVim, and the two functions are a direct port of the NeoVim functions.) My rationale in implementing generic functions this way was to make this extensible, if in the future a different provider is to be added to Vim, the scaffolding is already there.

I then started looking at the places where to hook these calls. For the most part, I've been looking for FEAT_CLIPBOARD and clip_star and hooking those there. It's doable, but there's quite a bit of ifdef'ery to get it all to work correctly... My idea is the prefer the clipboard provider is one is implemented (it's easy to just not ship one) but fallback to using the native +clipboard if it's enabled.

I'm also not completely sure how to bridge some existing features, such as the selection bridge.

I also feel it would significantly help to refactor some of the FEAT_CLIPBOARD code, so that the refactored code could be extended to implement both FEAT_CLIPBOARD and the "clipboard provider" and implement all the logic of detection, priorities, fallback, etc.

Before I go much further, I would like to get some early feedback:

Is such a feature (hooks to the clipboard registers) welcome and will a PR implementing it be accepted?
Is it OK to use an API that's compatible with the "clipboard provider" API implemented by NeoVim?
If so, should we add generic "provider" support to Vim (could be extended to more autoloaded providers), or should we keep the API (provider#clipboard#Call entry point) but make the C implementation more direct for the clipboard use case only for now?
How should we handle the interactions between a clipboard provider and the +clipboard feature?
Suggestions on code refactoring that should be done to support this? Should I reuse clip_star or some other parts of Clipboard_T? Specific suggestions would be much appreciated.
If we end up with the same (or very similar) API as NeoVim's, then would it be acceptable to ship the same (or very similar) autoload/provider/clipboard.vim with Vim runtimes? (And also the documentation for that module, including g:clipboard usage.)

I'm happy to work further on this! I really care about this feature and would like to see it in Vim. Let me know what would be a good implementation for you and I'm happy to deliver. Planning to deliver a complete implementation, including comprehensive test coverage and documentation.

Thanks!
Filipe

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Tony Mechelynck

unread,

Dec 21, 2020, 11:50:43 PM12/21/20

to vim/vim, Subscribed

No matter which utility accesses what is to Vim the "star" and "plus" register, on Unix-like platforms other than OSX they do it via functionalities of the X11 server because these registers are X11 registers. On Windows it's different: there they are identical, and both mean the Windows clipboard. On MacVim I don't know. So AFAIK putting, deleting and yanking into and from these registers, either via the p d q (etc.) Normal-mode commands, or via the :put :delete and :yank Ex-commands, is doing it by code. (Maybe you missed the ex-commands? Look them up in the Vim help.)
The getreg() and setreg() functions can also be used with these two registers. Look them up too if you haven't yet.
Otherwise, check the $VIMRUNTIME/autoload/provider/clipboard.vim (if that's where it is) in the Neovim distribution. It ought to be Vim script language, and my guess is that it shouldn't be too hard to make it work on Bram's Vim (maybe even by dropping it unchanged, or slightly changed, into ~/.vim/autoload/provider on Unix or into ~/vimfiles/autoload/provider on Windows — but it's only a guess: I know nothing of Neovim except that it is "a Vim look-alike", and I wouldn't feel a need for anything more than the above-mentioned Normal-mode commands, Ex commands and functions — but Vim script language is a language where I feel at ease, it doesn't feel foreign to me. YMMV.

Maxim Kim

unread,

Dec 22, 2020, 2:20:00 AM12/22/20

to vim/vim, Subscribed

I remember neovim clipboard support had an issue with visual block selection paste, did they manage to fix it? If not, would your implementation fix it? ( looks like not fixed neovim/neovim#1822 )

@tonymec :put , :delete and :yank are linewise and that is not always what you need.

Christian Brabandt

unread,

Dec 22, 2020, 2:51:52 AM12/22/20

to vim/vim, Subscribed

this is going to be a rabbit hole. While it allows for a more flexible approach, it adds a bit of complexity. Think about passing the converting the input to the encoding of the external provider and back and I believe Vim has its own magic to detect that from the systems clipboard interface. Then there is the issue to correctly detect what kind of selection has been pasted. And finally this adds a performance penalty, because calling external processes is more expansive than going directly through the OS interfaces (think about the netrw issue)

So this might actually be valuable for some corner cases where Vim is used (WSL, SSH, etc) but it will be tricky to get right for all corner cases. I agree that following the neovim interface would be good.

the following is just my personal opinion, Bram has the final word about it:

Is such a feature (hooks to the clipboard registers) welcome and will a PR implementing it be accepted?

I think yes, if it comes with tests and documentation.

Is it OK to use an API that's compatible with the "clipboard provider" API implemented by NeoVim?

From my side yes

If so, should we add generic "provider" support to Vim (could be extended to more autoloaded providers), or should we keep the API (provider#clipboard#Call entry point) but make the C implementation more direct for the clipboard use case only for now?

I think a generic provider would be okay and might be the most flexible.

How should we handle the interactions between a clipboard provider and the +clipboard feature?

I would say, add a new value to the clipboard option, to direct any clipboard interaction through the new provider and then the provider should probably be always callable, even for Vims that are linked without the +clipboard feature, if possible (this might not make sense for tiny vims).

If we end up with the same (or very similar) API as NeoVim's, then would it be acceptable to ship the same (or very similar) autoload/provider/clipboard.vim with Vim runtimes? (And also the documentation for that module, including g:clipboard usage.)

If this is okay from the neovim folks. Perhaps @bfredl or @justinmk could confirm that this would be okay.

Filipe Brandenburger

unread,

Dec 22, 2020, 1:14:00 PM12/22/20

to vim/vim, Subscribed

Thank you for the feedback! Very interesting points that you raise.

It seems that the provider interface is more suitable to fully implementing a feature and not overriding the internal implementation. (That's understandable in the NeoVim case, since they don't have the +clipboard feature and that part is also implemented using the provider.)

So for Vim's case, perhaps it would be better to just have a way to override the internal implementation? Perhaps something like a 'clipboardfunc' that points to a function that takes get/set calls to interact with an external clipboard? And then using that function (instead of the internal implementation of accessing the X11 clipboard) whenever it's set?

That might be even better for quick overrides and one-offs (you could set it temporarily or unset it temporarily in a function), and wouldn't interfere with the internal implementation unless it gets set.

I'll start working on a proof-of-concept for that. I'll post here when I have more. (Or perhaps post a PR if I get far enough into working code that implements that.)

Cheers!
Filipe

Foxe Chen

unread,

Sep 4, 2026, 12:00:00 AM (2 days ago) Sep 4

to vim/vim, Subscribed

64-bitman left a comment (vim/vim#7524)

@chrisbra I think this issue can be closed now

—

Reply to this email directly, view it on GitHub, or unsubscribe.

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Sep 4, 2026, 12:56:45 PM (2 days ago) Sep 4

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#7524)

Thanks, closing

—

Reply to this email directly, view it on GitHub, or unsubscribe.

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward