On Sat, 10 Feb 2024 11:34:19 +0100
Christian Brabandt <cbli...@256bit.org> wrote:
> On Fr, 09 Feb 2024, luca.saccar...@saccarosium.com wrote:
>
> > Hi all,
> > I would like to make a proposal for decoupling the clipboard
> > functionality from X11.
> >
> > I've study the code base for some time but I still need some help on
> > where and how exactly do this.
> >
> > The problem
> > ===========
> >
> > Currently in vim, on Linux, rely on X11 to interact with the system
> > clipboard. This come with the limitation that vim needs to be compiled
> > agaist X11. This means that the base vim package, in most distribution,
> > as no way to interact with the system clipboard which is a really nice,
> > sometimes essential, feature to have.
> >
> > If a normal user wants to have this feature they need to compile vim,
> > which is not something that everyone is comfortable doing, or install
> > gvim, which a lot of users don't want to have it installed.
> >
> > Also if you currently on wayland and use the `xterm_clipboard` feature
> > the startup time is significantly higher due to the start of an xwaland
> > instance on vim startup.
> >
> > Possible solutions
> > ==================
> >
> > 1. Rely on external tools
> >
> > This is what neovim does with his 'providers' [1] mechanism.
> > Basically they call at runtime external tools to interact with the system
> > clipboard (e.g. 'xclip' on Linux X11 or'pbcopy' on OSX).
> >
> > Advantages:
> > - Low cost in maintenance and in adding support for new operating systems,
> > since every OS either has a CLI clipboard utility already built-in or
> > available to download.
> > - It makes trivial to support more niche or esoteric setups, since you
> > can provide a simple variable to tell vim what commands to call
> > (example from neovim's implementation):
> >
> > let g:clipboard = {
> > \ 'name': 'myClipboard',
> > \ 'copy': {
> > \ '+': ['tmux', 'load-buffer', '-'],
> > \ '*': ['tmux', 'load-buffer', '-'],
> > \ },
> > \ 'paste': {
> > \ '+': ['tmux', 'save-buffer', '-'],
> > \ '*': ['tmux', 'save-buffer', '-'],
> > \ },
> > \ 'cache_enabled': 1,
> > \ }
> >
> > Disadvantages:
> > - The user needs, in the worst case scenario, to install an additional
> > package (but it is better than the current experience)
> > - There may be some performance penalties [2].
> >
> >
> > Recap
> > =====
> >
> > I'm personally in favor of the neovim approach (the first one) but I
> > would like to have some feedback on this.
> >
> > [1]: https://neovim.io/doc/user/provider.html#provider
> > [2]: https://github.com/neovim/neovim/issues/11804
>
> I personally don't like the Neovim approach for several reasons:
>
> - it puts the burden to configure the clipboard to the users. Yes, I
> know we can ship pre-configured clipboard provider, but initially this
> has to be configured by each user separately (and then later
> eventually merged into Vim)
> - I think, the clipboard functionality should work out of the box. There
> is a reason, why no other application uses a clipboard provider
> feature but implements this directly in the application
> - I think shelling out to an external clipboard provider causes a
> performance penalty, especially when pasting large amount of texts
> (a few years ago, we had an issue when using `:g/../d` which caused
> a huge slowdown, just because Vim was copying each delete into the X11
> clipboard. We added some logic to prevent this, but using a clipboard
> provider would make this experience worse)
I like Luca's first suggestion. Unix philosophy: use the tool meant for
the job. Why write and maintain logic for all platforms when dedicated
tools exist to do that one job.
As for the problem with copying large amount of text, my argument is: we
shouldn't use 'clipboard+=unnamedplus' all the time. Use vim's internal
clipboard for editing and interact with the system clipboard only when
necessary, i.e., with * or + registers.
However, your comment about existing plugins to manipulate system
clipboard in other ways is my comment, too. I use a plugin that relies
on OSC52 of my terminal emulator. So I don't have to fight with Windows
and X11 clipboards. But this isn't a solution for everyone since not
everyone uses a terminal emulator with OSC52 support. My argument is:
find a plugin that serves your purpose.
> - There are too many corner cases that need to be considered:
> - different encodings of the text being pasted
> - different selection types (character- block- or linewise)
> - It doesn't help with Vim tiny, since it doesn't support Vim script, so
> one should still need to re-compile Vim
> - If you are using xclip or xsel you would still require the X11
> libraries to work with the clipboard, so I don't think this gains us
> anything
>
>
> There are probably a few others, e.g. in my professional work, I have to
> jump to customer environments and work with what is installed there. I
> cannot start configuring clipboard provider (or install additional
> tools) just to do my work there. In addition, I am not sure, how this
> would work on containers and similar environments.
>
> I suppose if one really wants to, users can already make use of
> clipboard providers using some Vim plugin (with the restrictions
> mentions above), there shouldn't be anything hindering you to use
> external tools to interact with the clipboard already. That doesn't
> mean, we should get rid of the existing clipboard code however. I am not
> sure if such a Vim plugin exists.
>
> > 2. Create our own implementation for dealing with the system clipboard
> > without rely on X11
> >
> > Advantages:
> > - The user is ready to go without needing to install anything
> > - There shouldn't be a big performance loss
> >
> > Disadvantages:
> > - Maintenance in theory will be more difficult since I assume is not an
> > easy task to support all vim's targets while still support some
> > more esoteric/less common setups.
>
> Clipboard functionality is a feature of X11. I don't see how we could
> support this without X11 libraries available. I suppose Wayland supports
> something similar, but the fact remains, we need to connect to some
> existing frame work that enables the inter-process communication. We
> cannot just develop our own here.
>
> Thanks,
> Christian
--
Enan
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20240607184922.00000486%40gmail.com.
