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
