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)
- 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
--
I hear what you're saying but I just don't care.
--
--
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/ZcdRKzjvt7l2Yopg%40256bit.org.
