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.
- Fix an issue where CMAKE_BUILD_TYPE was not reflected during
construction.
- Remove the switch that uses the static library(-MTd, -MT) because it was
specified in the CMakeLists.txt of luv when building on MSVC.
related: https://github.com/luvit/luv/pull/461
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.
As gcc10 uses -fno-common by default, global variables declared with the
same name more than once is not allowed anymore revealing this issue.
We need to define it as extern to access it.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1799680
Instead of declaring an enum, this creates a global variable. As gcc10
uses -fno-common by default, global variables declared with the same
name more than once is not allowed anymore revealing this issue.
Each time this header is included, we define the enum name as a global
variable.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1799680
Instead of declaring an enum, this creates a global variable. As gcc10
uses -fno-common by default, global variables declared with the same
name more than once is not allowed anymore revealing this issue.
Each time this header is included, we define the enum name as a global
variable.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1799680
Instead of declaring an enum, this creates a global variable. As gcc10
uses -fno-common by default, global variables declared with the same
name more than once is not allowed anymore revealing this issue.
Each time this header is included, we define the enum name as a global
variable.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1799680
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
Problem: Multibyte characters in 'listchars' don't work correctly if
'linebreak' is also enabled. (Martin Tournoij)
Solution: Make it work correctly. (Christian Brabandt, closesvim/vim#4822,
closesvim/vim#4812)
69cbbecf54
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
- Move uv_stop(), it still causes a "leak" on exit somehow.
- Tenatively restore `UV_RUN_DEFAULT`. It shouldn't hang since we
clobber the handles via `uv_walk((h)=>uv_close(h))`. Although this
still "leaks" on exit, it's faster than the 2-second timeout.
fix#11820fix#7376
- Call uv_stop().
- Restore `uv_loop_close` condition (braindead cosmetic change from
a2efc9cf8b that caused uv_loop_close *not* to be called if
wait=false, sorry).
Not doing `uv_walk(() => uv_close)`: see source comment for explanation.
fix#11820fix#7376
Q: Should we restore use of `UV_RUN_DEFAULT`/`UV_RUN_ONCE` (removed in
a2efc9cf8b)?
A: The while-loop (hopefully) achieves the same purpose while avoiding
a hang.
