| Commit message (Collapse) | Author | Age |
... | |
| |
| |
| |
| |
| | |
This also fixes `:Man!`, which wasn't setting 'iskeyword' to contain
parentheses, etc.
|
| |
| |
| |
| |
| | |
- 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.
|
| |
| |
| |
| |
| |
| | |
Problem: Tutor does not check $LC_MESSAGES.
Solution: Let $LC_MESSAGES overrule $LANG. (Miklos Vajna, closes vim/vim#4112)
https://github.com/vim/vim/commit/b44b7add8ae8e15328b4f68c3caf511bd9aaac8c
|
| |
| |
| |
| | |
Port javascript autocomplete file only.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 63f0ca326322376271, `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
|
| |
|
|\
| |
| | |
runtime: Patch xml, xmllint, xmlformat filetypes
|
| |
| |
| |
| | |
vim/vim@eab6dff19f387469a200011bc6cf3508f5e43a4a
|
| |
| |
| |
| | |
vim/vim@96f45c0b6fc9e9d404e6805593ed1e0e6795e470
|
|/
|
|
|
|
| |
Restricted mode (-Z) has been removed per #11996.
Some runtime files had lingering error handling (error
identifier `E145`) so I cleaned them up.
|
|
|
|
| |
CPAN tests are unreliable on Windows.
CI does the same to reduce flaky,slow builds.
|
|
|
| |
Fixes #13189
|
|
|
|
|
|
|
|
| |
Python 3.9 was released, so we need to add support for the upcoming Python 3.10.
Python 3.5 and earlier reached their end-of-life.
PEP 478: Python 3.5 Release Schedule: https://www.python.org/dev/peps/pep-0478
PEP 596: Python 3.9 Release Schedule: https://www.python.org/dev/peps/pep-0596
PEP 619: Python 3.10 Release Schedule: https://www.python.org/dev/peps/pep-0619
|
|
|
|
| |
See vim/vim@7ff7846
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
|/
|
| |
fixes #12768
|
|
|
|
|
|
| |
Problem: Filetype test fails on MS-Windows.
Solution: Remove "^" from pattern.
https://github.com/vim/vim/commit/aa9675a61d510c4a56c3845d05b32b1ef780d119
|
|
|
|
|
|
| |
Problem: /usr/lib/udef/rules.d not recognized as udevrules.
Solution: Adjust match pattern. (Haochen Tong, closes 36722)
https://github.com/vim/vim/commit/624b6eaf20f3e8c669425b6a32f17fb9ec2ebbd2
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|\
| |
| | |
man.vim: Refactor verify_exists to unset $MANSECT as needed
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|
|
|
| |
fixes #12410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Plaform: Windows 10
run `cmd /c gem list -ra ^^neovim$`
*** REMOTE GEMS ***
minitest-neovim (0.1.0)
neovim (0.7.1, 0.7.0, 0.6.2, 0.6.1, 0.6.0, 0.5.1, 0.5.0, 0.4.0, 0.3.3, 0.3.2, 0.3.1, 0.3.0, 0.2.5, 0.2.4, 0.2.3, 0.2.2, 0.2.1, 0.2.0, 0.1.0, 0.0.6, 0.0.5, 0.0.4, 0.0.3, 0.0.2, 0.0.1)
run `cmd /c gem list -ra "^^neovim$"`
*** REMOTE GEMS ***
neovim (0.7.1, 0.7.0, 0.6.2, 0.6.1, 0.6.0, 0.5.1, 0.5.0, 0.4.0, 0.3.3, 0.3.2, 0.3.1, 0.3.0, 0.2.5, 0.2.4, 0.2.3, 0.2.2, 0.2.1, 0.2.0, 0.1.0, 0.0.6, 0.0.5, 0.0.4, 0.0.3, 0.0.2, 0.0.1)
|
|
|
|
| |
3.9's scheduled for beta release today.
https://www.python.org/dev/peps/pep-0596/
|
|
|
| |
Co-authored-by: BodongLiKolmostar <bodong.li@kolmostar.com>
|
|
|
|
|
|
|
|
|
| |
(#12124)
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.
|
|
|
|
|
|
| |
netrw thinks it's a remote file due the name of a terminal buffer (term://),
but a terminal buffer isn't a file.
Fixes https://github.com/neovim/neovim/issues/4612#issuecomment-600321171
|
|
|
|
|
|
|
|
| |
Fallback to simply globbing the tag we're given. This matches the
original behaviour of `man.vim`, prior to c6afad78d39aa.
fixes #11794
closes #11918
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Co-Authored-By: Peter Lithammer <peter.lithammer@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix #11753
close #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).
|