[vim/vim] Clipboard provider support (Issue #12419)
依云
I'm trying to write a proper clipboard provider plugin that behaves correctly on Linux, i.e. own clipboards and send out data on request, instead of Neovim style's "send on copy" method. This makes it behave as expected with primary selection, and also reduce unnecessary data transfer (e.g. selecting large part of text, or over a network).
This project aims to provide clipboard support for Vim in both Wayland terminals and remote sessions (e.g. via ssh). (X11 forward is laggy and requires system libraries. Wayland one (waypipe) isn't any better. It's too much for users who just want remote copy&paste.)
However, while the copy-from-vim part seems to go well, paste-into-vim part won't be as good as native because lacking of support from Vim.
Describe the solution you'd like
Vim provides something like 'foldexpr', 'formatexpr' but for retrieving register contents. It can be limited to only '+' & '*'.
Describe alternatives you've considered
Mapping various related key strokes like jasonccox/vim-wayland-clipboard. This does work for simple cases but it won't work for things like noremap, @* or getreg('*').
Additional context
I'm using job and channel features to implement my stuff. They have huge potential to extend Vim outside Vim's source code. Some days ago someone mentioned dark theme switching, and I'm considering a '+clientserver' equivalent. These can also be implemented as external programs and interact with Vim via jobs.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> I'm trying to write a proper clipboard provider plugin that behaves
> correctly on Linux, i.e. own clipboards and send out data on request,
> instead of Neovim style's "send on copy" method. This makes it behave
> as expected with primary selection, and also reduce unnecessary data
> transfer (e.g. selecting large part of text, or over a network).
>
> This project aims to provide clipboard support for Vim in both Wayland
> terminals and remote sessions (e.g. via ssh). (X11 forward is laggy
> and requires system libraries. Wayland one (waypipe) isn't any better.
> It's too much for users who just want remote copy&paste.)
>
> However, while the copy-from-vim part seems to go well, paste-into-vim
> part won't be as good as native because lacking of support from Vim.
>
>
> Vim provides something like 'foldexpr', 'formatexpr' but for
> retrieving register contents. It can be limited to only '+' & '*'.
see the internal "API" used. There are two versions: one for the X11
selection mechanism and one for what is commonly called a clipboard.
For a "regular clipboard" Vim could call a user function when a
selection has been made. That function could then copy the text and
store it somewhere, either inside Vim or elsewhere. A copy needs to be
made, because the buffer text can be changed after selecting it. When
pasting Vim would call another function to obtain the clipboard
contents.
For the X11 selection method there would be functions for owning the
selection, losing the selection, fetching the selected text, keep state
of whether the selection is owned, and probably some more.
On top of that you need to be able to handle different encodings and
types of text. E.g. for copy/paste between two Vim instances a block
of text can be passed, while between Vim and a generic text application
it would just be lines of plain text. For the X11 selection you would
also need to be able to handle the X11 requests asynchronously.
You may argue that you won't need all of this, but once this is started
someone will want more, and eventually all of it. It's better to do it
properly from the start. Thus this will be quite a bit of work.
--
CVS sux, men don't like commitment
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
try 'yankring' a classic vim plugin, though not sure if it matched your demand fully or not.
// but nowdays vim had no shared shared clipboard 'problem' maybe is a Luck !! 🤣
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
依云
For a "regular clipboard" Vim could call a user function when a selection has been made.
When a selection starts, there is a ModeChange event. When user explicitly copies to * / + there is a TextYankPost event. Vim already maintains the * and + registers so when a paste request is made by another application, Vim can get the content with getreg() (if in Visual mode, the plugin gets selected text).
For the X11 selection method there would be functions for owning the selection, losing the selection, fetching the selected text, keep state of whether the selection is owned, and probably some more.
Currently I'm doing this:
- on Visual mode starts or yanking into
*, send a request to my external program to own the selection - the external program sends a "disown" message and the plugin updates state and highlight
- the external program sends a "receive" message and the plugin gets selected text (Visual mode) or
getreg('*')and replies to the external program
For + register it's simpler as there is no select-to-copy thing.
(I haven't written a fully working external program yet; just a dummy one to communicate with Vim. The other part to communicate with the system should be no problem.)
On top of that you need to be able to handle different encodings and types of text.
This can be done by plugin too. I'm not familiar with the encoding problem as I'm using UTF-8 exclusively but the plugin can check the 'encoding' option. For different selection types, the plugin can check visualmode() and add info about that. The paste Vim needs to request a Vim-special content type however, so the requested 'pastefunc' needs to return both text and optional selection type (and it needs to be able to indicate no text available).
Of course, Vim could provide dedicated support for all related things, instead of letting the plugin figures them out. But that's more work to do.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #12419 as completed via 67860ef.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.