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].
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.
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
--
--
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/1NQL8S.2Q8ZGK1O01692%40saccarosium.com.
