Mainly configuration and RPC infrastructure can be considered "done". Specific requests and their callbacks will be improved later (and also served by plugins). There are also some TODO:s for the client itself, like incremental updates.
Co-authored by at-tjdevries and at-h-michael, with many review/suggestion contributions.
Problem: If spellfile is missing, then "set spell" in modeline/sandbox
fails with a non-obvious error.
Solution: Check for sandbox early and give a meaningful error.
Fixes#11359
Test case:
# test.latex has `% vim: set spelllang=hu:`
# no spell file for `hu` yet!
nvim -u NORC --cmd 'autocmd FileType tex setlocal spell' --cmd 'set modeline' test.latex
Before:
No spell file for "hu" in utf-8
Download it?
Downloading hu.utf-8.spl...
Error detected while processing /usr/local/share/nvim/runtime/autoload/netrw.vim:
line 583:
E12: Command not allowed from exrc/vimrc in current dir or tag search: au WinEnter *^Iif &ft == "netrw"|call s:NetrwInsureWinVars()|endif
Error detected while processing function spellfile#LoadFile[60]..spellfile#Nread[13]..netrw#NetRead[4]..<SNR>67_NetrwOptionsSave:
line 66:
E171: Missing :endif
Error detected while processing function spellfile#LoadFile[60]..spellfile#Nread:
line 13:
E171: Missing :endif
Error detected while processing function spellfile#LoadFile:
line 60:
E171: Missing :endif
Error detected while processing modelines:
line 1:
E12: Command not allowed from exrc/vimrc in current dir or tag search
After:
Error detected while processing function spellfile#LoadFile:
line 5:
E605: Exception not caught: Cannot download spellfile in sandbox/modeline. Try ":set spell" from the cmdline.
Error detected while processing modelines:
line 1:
E12: Command not allowed from exrc/vimrc in current dir or tag search
sys.path.remove("") raises ValueError if the item is missing.
https://docs.python.org/3/library/functions.html#filter:
> filter(function, iterable) is equivalent to the generator expression (item
> for item in iterable if function(item))
fixes#11293
In order to find if there was already an open man page, the :Man command
would cycle through each window to see if &ft=='man'. This triggers
autocmds, e.g. BufEnter, unnecessarily and can have unexpected
side-effects.
Change the logic to check each window's ft without switching to it
unless it is actually a man window.
Signed-off-by: Joshua Rubin <me@jawa.dev>
The Python provider was special (via [1]), and would continue to do
checks with `0` being set explicitly even.
This was fixed in #11044 (45447e3b6), ref: #11040.
This extends it to use the same method with all providers.
1: https://github.com/neovim/neovim/pull/8047
This reverts part of ade88fe4c [1].
This is required for `let g:python3_host_prog = 'python'` etc, where it
should get picked up from PATH.
Without this it would show:
```
- INFO: pyenv: Path: /home/user/.pyenv/libexec/pyenv
- INFO: pyenv: Root: /home/user/.pyenv
- INFO: Using: g:python3_host_prog = "python"
- ERROR: "python" was not found.
- INFO: Executable: Not found
- ERROR: Detected pip upgrade failure: Python executable can import "pynvim" but not "neovim": python
- ADVICE:
- Use that Python version to reinstall "pynvim" and optionally "neovim".
pip3 uninstall pynvim neovim
pip3 install pynvim
pip3 install neovim # only if needed by third-party software
```
Note that it additionally causes a weird error
("Detected pip upgrade failure"), due to `s:check_bin` emptying
`python_exe` (because the non-absolute file not being readable), and
`provider#pythonx#DetectByModule('pynvim', a:version)` from 75593e6fce
then just getting the value from the host var again (without actual
checks).
This is implicitly fixed via this patch now (because it is skipped), but
could need some improvement in this regard probably.
With this patch it resolves it (for a virtualenv where pynvim is not
made available intentionally):
```
- INFO: pyenv: Path: /home/daniel/.pyenv/libexec/pyenv
- INFO: pyenv: Root: /home/daniel/.pyenv
- INFO: Using: g:python3_host_prog = "python"
- WARNING: $VIRTUAL_ENV exists but appears to be inactive. This could lead to unexpected results.
- ADVICE:
- If you are using Zsh, see: http://vi.stackexchange.com/a/7654
- INFO: Executable: /home/daniel/.pyenv/shims/tmp-system-deoplete.nvim-f205aF/python
- ERROR: Command error (job=11, exit code 1): `'/home/daniel/.pyenv/shims/tmp-system-deoplete.nvim-f205aF/python' -c 'import sys; sys.path.remove(""); import neovim; print(neovim.__file__)'` (in '/home/daniel/.dotfiles/vim/plugged/deoplete.nvim')
Output: Traceback (most recent call last): File "<string>", line 1, in <module>ModuleNotFoundError: No module named 'neovim'
Stderr: Traceback (most recent call last): File "<string>", line 1, in <module>ModuleNotFoundError: No module named 'neovim'
- INFO: Python version: 3.7.4
- INFO: pynvim version: unable to load neovim Python module
- ERROR: pynvim is not installed.
Error: unable to load neovim Python module
- ADVICE:
- Run in shell: pip3 install pynvim
```
Note: this appears to display the error twice via "Output:" and
"Stderr:".
1: https://github.com/neovim/neovim/pull/8784
Instead of deciding provider status in eval_has_provider, move the
decision to the provider Vim scripts.
Previously, provider loading worked as follows:
1. eval_has_provider() verified provider availability by searching for
the provider#providername#Call function and cached this verificaion as a static
variable for some providers
2. providers short-circuited on loading to prevent the definition of the
Call function (with the exception of the node provider that did not)
This commit changes the expected interface between nvim and its
providers to facilitate provider reloading, by splitting the
verification of the provider from the availability of the Call function.
eval_has_provider() now checks for a provider#providername#enabled
variable. It is up to the provider script to set this to 0 or 1
accordingly. eval_call_provider() remains unchanged.
All providers hosting a Call function were updated to respect this.
The clipboard provider now has a Reload function to reload the
provider.
`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
