Executing `:python`, and similar commands that rely on `eval_call_provider()`,
while the accompanying provider it not available, leads to this error message:
E117: Unknown function: provider#python#Call
This doesn't say much to a user. Since we introduced `:checkhealth` for this
very reason, we now point to it for further diagnosis.
Fixes#3577
The macOS preferences have a section called `Language & Region`. There is always
at least one language defined, the primary language.
CFLocaleCopyPreferredLanguages() returns the languages defined in that section,
the first element being the primary language.
Use the primary language in case CFLocaleCopyCurrent() returns NULL.
In the case that the above fallback does not work either, which is very
unlikely, log the error and continue with an empty $LANG.
References #9134
Problem: 'commentstring' not used when adding fold marker in C.
Solution: Require white space before middle comment part. (mostly by
Hirohito Higashi)
4af7259b2b
Problem: Using an external diff program is slow and inflexible.
Solution: Include the xdiff library. (Christian Brabandt)
Use it by default.
e828b7621c
vim-patch:8.1.0360
vim-patch:8.1.0364
vim-patch:8.1.0366
vim-patch:8.1.0370
vim-patch:8.1.0377
vim-patch:8.1.0378
vim-patch:8.1.0381
vim-patch:8.1.0396
vim-patch:8.1.0432
Problem: 'commentstring' not used when adding fold marker. (Maxim Kim)
Solution: Only use empty 'comments' middle when leader is empty. (Christian
Brabandt, closesvim/vim#3670)
539328197c
Comparing `vimCommand` from Vim's runtime/syntax/vim.vim, one can see
that "augroup" and similar commands are conspicuously missing. They are
handled specially (`vimAugroupKey`, `vimAutoCmd`).
Excluding them from the generated `vimCommand` keyword list, fixes their
highlighting.
closes#9327
Install gperf using package manager instead of building it from source.
When building/installing gperf from source, its install step requires
`texi2pdf` which randomly goes missing on Travis:
cd doc; /usr/bin/make install
make[1]: Entering directory '/home/travis/nvim-deps/build/src/gperf/doc'
cd . && rm -f gperf.aux gperf.toc gperf.cp gperf.fn gperf.ky gperf.pg gperf.tp gperf.vr gperf.log gperf.cps
cd . && texi2pdf gperf.texi
/bin/sh: 1: texi2pdf: not found
It's nice to test the "bundled" deps on Travis, but that gets enough
exercise on Windows and macOS, which are the platforms that actually
need "bundled" gperf.
Problem: execute() does not work in completion of user command. (thinca)
Solution: Switch off redir_off and restore it. (Ozaki Kiichi, closesvim/vim#2492)
2095148277
Before this commit, if user does this:
let g:node_host_prog = '~/.nvm/versions/node/v11.3.0/bin/neovim-node-host'
the "~/" is not expanded to user's home directory.
`:help g:ruby_host_prog` suggests a path with "~/" so technically we
already claimed to support this.
closes https://github.com/neovim/node-client/issues/102
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.
As of CMake 3.12, check_include_files() also link the check executable
against the libraries listed in CMAKE_REQUIRED_LIBRARIES. Therefore we
should unset the CMAKE_REQUIRED_* variables after each respective use to
avoid them unnecessarily bleeding into other checks.
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
