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).
This makes it possible to restore the working directory of :terminal
buffers when reading those buffers from a session file.
Fixes#11288
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
