Problem: A plugin cannot easily expand a command like done internally.
Solution: Add the expandcmd() function. (Yegappan Lakshmanan, closesvim/vim#4514)
80dad48c50
Problem: :echomsg and :echoerr do not handle List and Dict like :echo does.
(Daniel Hahler)
Solution: Be more tolerant about the expression result type.
461a7fcfce
Add lua functional tests for :echo,:echon,:echomsg,:echoerr
because nvim did not port "test_" functions from Vim
that modify internal state.
Testing :echoerr via try/catch is sufficient.
This changes the `textDocument/references' callback to annotate the
locations returned by the server with the content present at the
locations range.
The quickfix list then looks as follows:
cr8/insert_fake_data.py|17 col 32| from .misc import parse_table, parse_version
cr8/insert_fake_data.py|43 col 15| version = parse_version(r['rows'][0][0])
cr8/java_magic.py|8 col 22| from cr8.misc import parse_version
cr8/java_magic.py|30 col 19| version = parse_version(fst)
cr8/java_magic.py|33 col 16| return parse_version(version_str)
Instead of:
cr8/insert_fake_data.py|17 col 32|
cr8/insert_fake_data.py|43 col 15|
cr8/java_magic.py|8 col 22|
cr8/java_magic.py|30 col 19|
cr8/java_magic.py|33 col 16|
haskell-ide-engine sends `hover` payloads as follows:
{
contents = {
kind = "markdown",
value = "\n```haskell\nfoo :: Either String (Integer, Text)\n```\n`foo` *local*"
},
range = {
end = {
character = 5,
line = 57
},
start = {
character = 2,
line = 57
}
}
}
`value` starts with `\n`. The logic in `convert_input_to_markdown_lines`
threw away the whole information.
Allow duplicates so that in languages with overloaded functions it will
show all signatures.
E.g. instead of having a single (last one wins)
add(int index, String element)
It shows all signatures:
add(String e) : boolean
add(int index, String element) : void
fix: #11826
Some lanuguage servers return complementary candidates whose prefixes do not match are also returned.
So we exclude completion candidates whose prefix does not match.
ex) Microsoft python-language-server, rust-analyzer
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
Problem: MS-Windows: Cannot interrupt gdb when program is running.
Solution: Add debugbreak() and use it in the terminal debugger.
Respect 'modified' in a prompt buffer.
4551c0a9fc
Problem: Terminal debugger only works with the terminal feature.
Solution: Make it also work with a prompt buffer. Makes it possible to use
on MS-Windows. Various other improvements. (closesvim/vim#3012)
b3307b5e7e
Use the logic explained in the softtabstop help section for defining
the tabSize parameter in formatting requests. This means that:
- if softtabstop is 0, tabstop is used
- if softtabstop < 0, shiftwidth is used
- if softtabstop > 0, softtabstop is used
When inserting spaces instead of tabs, softtabstop is used in vim.
Therefor it would be more logical to use it when formatting instead
of the current tabstop.
Using `vim.lsp.buf.rename()` can result in receiving a TextEdit that
affects a file for which there is no active or loaded buffer.
In that case `api.nvim_buf_get_lines(...)` returned an empty result,
leading to an error.
Closes https://github.com/neovim/neovim/issues/11790
These had broken encodings, set it to UTF-8. All remianing Neovim
non-ASCII documentation files are UTF-8 encoded. And so are their Vim
original versions.
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).
