`wl-copy` by default tries to determine the mime type of a copied bit of
text. From the [readme](https://github.com/bugaevc/wl-clipboard):
> wl-copy automatically infers the type of the copied content by running
> xdg-mime(1) on it.
So copying a Ruby script from Nvim may store it in the Wayland clipboard
as mime-type `application/x-ruby`.
This is a small reproduction without Nvim:
$ cat test.rb
#!/usr/bin/env ruby
puts 'hello world'
$ cat test.rb | wl-copy
$ wl-paste --list-types
application/x-ruby
This commit fixes that by telling wl-copy that all text copied from
Nvim has the mime type `text/plain`.
$ cat test.rb | wl-copy --type text/plain
$ wl-paste --list-types
text/plain;charset=utf-8
PR #9304 added support for functions in clipboard providers. As part of
the PR I meant to move two checks in the provider code out of an if
statement into separate statements and adding additional checks for
g:clipboard attributes - as it turns out the code is wrong and it does
not implement additional checks while it adds two conditions that make
very little sense
type(g:clipboard['copy']) #isnot# v:t_func
what would make sense would be something along the lines of
type(g:clipboard['copy']['+']) #isnot# v:t_func
but might not be what we want either, so I'm reverting this.
Up to now g:clipboard["copy"] only supported string values invoked as
system commands.
This commit enables the use of VimL functions instead. The function
signatures are the same as in provider/clipboard.vim. A clipboard
provider is expected to store and return a list of lines (i.e. the text)
and a register type (as seen in setreg()).
cache_enabled is ignored if "copy" is provided by a VimL function.
The order was swapped in #4150 to prefer `xsel` but there wasn't a clear
explanation. Meanwhile, `xsel` has been neglected upstream.
Let's trying preferring `xclip` again, we've had a few reports of
problems with `xsel`.
closes#7237
ref #5853
ref #7449
On some versions of macOS, pbcopy doesn't work in tmux <2.6
https://superuser.com/q/231130
Fallback to tmux in that case.
Add a healthcheck for this scenario.
- Show hint only once per session.
- provider#clipboard#Call(): prevent recursion
- provider#clear_stderr(): use has_key(), because :silent! is still
captured by :redir.
closes#7184
redir_write():
- This is a "batch" operation which was not yet covered by
start_batch_changes()
adjust_clipboard_name():
- msg() and friends during :redir will, of course, cause redir_write()
to try to capture that message, which causes recursion.
- EMSG() here is trouble: if it interrupts :redir it is a mess.
Rather than deal with the mess, show a non-error message.
closes#7182closes#7184closes#7183
ref #6048
ref #7032
Never throw an error when provider/clipboard.vim is sourced for the first time.
Save the error instead and expose it via `provider#clipboard#Error()`, mimicking
provider/python.vim.
This avoids the issue of nvim started daemons causing mountpoints to be
unmountable. This is currently the only place in runtime/ where this
calling convention occurred.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
xsel and xcopy may be available even if a valid X display is not. Also,
the availability of X may change at any time, so check on each
invocation.
Closes#1509.
Clipboard is implemented with platform-specific shell commands, and python is
implemented with the external plugin facility (rpc#* functions). The
script_host.py file(legacy python-vim emulation plugin) was moved/adapted from
the python client repository.
