The current guidance for install Python packages is to use
python -m pip install <package_name>
Instead of
pip install <package_name>
This ensures that one is using the version of pip that is tied to the
environment's interpreter (and, thusly, its packages). This has [been
endorsed by a core
maintainer](https://snarky.ca/why-you-should-use-python-m-pip/) as
being the recommended way to invoke pip.
As there currently are a few places where the old invocation was used,
attempt to bring them in line.
Fixes#14234
- If the shada file is set with shada option n, use it.
- If the shadafile is NONE, it does not check for file read/write access.
- If the shada file does not exist, try to create it.
Here I use a negative number to decide whether the count has been
explicitly set. I think it unlikely that negative sections will ever be
created given that negative numbers complicate argument handling:
```
$ man -1 foo
man: invalid option -- '1'
```
and given that there's already precedence for alphanumeric sections like
`3p`, `3x`, `n`, etc.
---
This does work, though:
```
$ man -S -3 baz
```
With `man baz.-3` and `man 'baz(-3)'`, (GNU) man *might* consider `-3`
internally as a section, but in the end reports as if the whole
argument was the name of a topic:
```
$ man 'baz(-3)'
No manual entry for baz(-3)
```
---
Closes#13411.
In commit 63f0ca3263, `tagfunc` was introduced to
`runtime/autoload/man.vim`. Nonetheless the tag function instead
of using a short buffer name (e.g. `man://foo(3)`) uses the full
path to the man page (e.g. `man:///usr/share/.../foo.3.gz`). This
behaviour is inconsistent with `:Man!`, thus this commit.
Closes#13334
Problem: ruby#Detect() and node#Detect() don't return a [prog, err] pair
which means callers must special-case them.
Solution: align their return signatures with the perl/pythonx providers.
* support for :perl, :perlfile, :perldo and perleval()
* document that the perl provider doesn't currently work on Windows
* document that the perl legacy interface is now also supported
* added perleval() documentation
* import legacy perl interface tests
* only perl 5.22+ is supported
* healtcheck: use g:perl_host_prog if its set instead
using just 'perl' isn't correct as it may not be the version requested.
ditto for 'cpanm', rather go through 'App::cpanminus' to find the latest
perl version
using just 'perl' isn't correct as it may not be the version requested.
ditto for 'cpanm', rather go through 'App::cpanminus' to find the latest
perl version
I removed the SunOS stuff since no one uses SunOS and I've never tested
it on there.
I removed the section_flag init as we can just use -S instead of -s
and -S is used by every implementation as far as I know.
This brings man#init's time from 50-70ms to 15-20ms for me.
Closes#12318
Related #6766
Related #6815
Also, kudos to @zsugabubus for fixing a related issue in #12417
This also prevents any sorting of the paths from man. We need to
respect the order we get from it otherwise you end up loading
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man/man1/ls.1
on MacOS instead of /usr/share/man/man1/ls.1
Also cleaned it up a little and made it faster.
Closes#9159 and #9271
Also changes man#extract_sect_and_name_ref to only return a single
section at a time. This fixes a bug in its usage in man#goto_tag
where get_paths would be called with multiple sections and it does
not support that.
I noticed that our tagfunc doesn't obey b:man_default_sects and
I'll fix that next.
When UV_OVERLAPPED_PIPE was used for the pipe passed to the child process, a
problem occurred with the standard input of the .Net Framework application
(#11809). Therefore, add the overlapped option to jobstart() and change it so
that it is set only when necessary
On some versions of Windows, WSL is unable to execute symbolic links to
Windows executables (microsoft/WSL#3999). As a workaround for that problem
this changes to use resolve() on WSL if win32yank was a symbolic link.
fixes#12113.
cpanm cannot look for Perl modules from root directories
without sudo so it creates '~/perl5/' and look for Perl modules in there.
Whether this directory existed before running cpanm or not,
cpanm returns a warning to advice the user to setup local::lib
in order to use modules in '~/perl5/' and exits with error code 0.
Each line in the warning always starts with '!'.
Display this warning to the user.
Continue parsing the version number if the warning can be ignored
because lines that are not prefixed with '!' are valid output.
Fix#11858
cpanm outputs a warning that suggest to use 'sudo' or use local::lib.
cpanm exits with 0 so nvim thinks that the command worked.
cpanm output that starts with "!" is likely an error.
Close#11858
fix#11753close#11781
The virtualenv troubleshooting in the Python provider health checks is
supposed to help the user determine whether running Python from Neovim
(as in `system('python')` or `system(exepath('python'))`) will use the
correct executable when a virtualenv is active. Currently however, it
issues spurious warnings in legitimate setups, and conversely, fails to
warn about potentially problematic ones.
See https://github.com/neovim/neovim/issues/11753#issuecomment-578715584
for a more detailed analysis, but at a high level, this is due to two
things:
- the virtualenv check is part of the Python provider check defined in
`s:check_python`, which uses a roundabout and sometimes erroneous way of
determining the Python executable
- more generally, it shouldn't be part of the provider check at all,
because it's not really related to the Python *provider*, i.e. the
Python executable which can communicate with Neovim via `pynvim`, but to
the Python the user is editing source files for, which typically
shouldn't even have `pynvim` installed
This patch reimplements the virtualenv check and factors it out into its
own separate function, which is however still kept in
`health/provider.vim` alongside the rest of the Python troubleshooting,
since troubleshooting all Python-related stuff in one place is probably
a good idea in order to alleviate any potential confusion (e.g. users
who run only provider checks might be left wondering whether their
virtualenv Python was properly detected if the report only shows their
global Python as the provider used by Neovim).
The old `:Man` implementation would take either the word under
the cursor, or the argument passed in, and load that as a man page.
Since we now use 'tagfunc' and look for all relevant man-pages, if
your system has several (i.e. same name, different sections), we return
several, giving the user an option.
This works for most tag commands except `:tjump`, which will
fail if there's multiple tags to choose from. This just happens to
be what the cscope code uses (it actually attempts to prompt the
user, but this fails).
test_registers.vim can fail even if a clipboard manager is running.
If a clipboard manager is not running, this test always fails with xclip.
Use xsel as a workaround.
https://github.com/astrand/xclip/issues/20 suggests closing stdout
when sending input via stdin.
Environment
- Ubuntu Xenial
- Vim 7.4 (any app with broken clipboard code will do)
- Neovim nightly
Steps to reproduce:
0. Start the clipboard manager.
1. Open a file in Vim on Linux.
Vim should have +clipboard enabled.
'set clipboard='
2. Yank some text to the clipboard register.
3. Quit Vim.
4. Run 'cd /path/to/neovim/repo/'
5. Run 'make oldtest'.
Do not run any individual tests.
They likely pass with or without this fix.
Before fix: test_registers.vim can fail.
After fix: test_registers.vim always passes.
Close https://github.com/neovim/neovim/issues/7958https://wiki.ubuntu.com/ClipboardPersistence#The_state_of_things
This addresses a minor quality problem with the recent `'tagfunc'`
changes for `man.vim` (see [link]).
Currently, with the cursor on a parenthese, hitting `K` will jump us to
the man page of the next mentioned entry, instead of the one to which
the parenthese (or section number) belongs.
```
pcrepattern(3), terminfo(5), glob(7), regex(7).
e.g. ^ e.g. ^
```
Adding the parentheses to `'iskeyword'` means we correctly handle these cases too.
[link]: https://github.com/neovim/neovim/pull/11280#discussion_r348342357
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
