Problem: Completing "call g:" returns entries with just "g:". (Naohiro Ono)
Solution: Skip empty strings returned by get_user_func_name(). (closesvim/vim#8753)
069f90852f
Problem: Some code is not tested.
Solution: Add some more tests. (Dominique Pellé, closesvim/vim#8735)
bd9e796125
Include Test_confirm_write_partial_file() anyway, even though it will
not be run.
Problem: Finding completions may cause an endless loop.
Solution: Use a better way to check coming back where the search started.
(Andy Gozas, closesvim/vim#8672, closesvim/vim#8671)
6a230c6b32
Problem: win_enter_ext() has too many boolean arguments.
Solution: use one flags argument with defined values.
d61f2f772a
Include some style changes to appease the linter.
N/A patches for version.c:
vim-patch:8.2.3289: compiler warning for unused variable with small features
Problem: Compiler warning for unused variable with small features.
Solution: Rearrange #ifdefs.
f18e8a969a
vim-patch:8.2.3298: build failure with small features
Problem: Build failure with small features.
Solution: Add #ifdef.
6f6d58c380
vim-patch:8.2.3331: Coverity warns for using value without boundary check
Problem: Coverity warns for using value without boundary check.
Solution: Add a boundary check.
ed7cb2df35
vim-patch:8.2.3354: build failure with +byte_offset but without +textprop
Problem: Build failure with +byte_offset but without +textprop. (John
Marriott)
Solution: Adjust the #ifdef.
92755bba30
vim-patch:8.2.3355: MS-Windows: compiler warning for 64-32 bit conversion
Problem: MS-Windows: compiler warning for 64-32 bit conversion.
Solution: Add type casts.
434df7a401
## Overview
- Move vim.lsp.diagnostic to vim.diagnostic
- Refactor client ids to diagnostic namespaces
- Update tests
- Write/update documentation and function signatures
Currently, non-LSP diagnostics in Neovim must hook into the LSP subsystem. This
is what e.g. null-ls and nvim-lint do. This is necessary because none of the
diagnostic API is exposed separately from the LSP subsystem.
This commit addresses this by generalizing the diagnostic subsystem beyond the
scope of LSP. The `vim.lsp.diagnostic` module is now simply a specific
diagnostic producer and primarily maintains the interface between LSP clients
and the broader diagnostic API.
The current diagnostic API uses "client ids" which only makes sense in the
context of LSP. We replace "client ids" with standard API namespaces generated
from `nvim_create_namespace`.
This PR is *mostly* backward compatible (so long as plugins are only using the
publicly documented API): LSP diagnostics will continue to work as usual, as
will pseudo-LSP clients like null-ls and nvim-lint. However, the latter can now
use the new interface, which looks something like this:
```lua
-- The namespace *must* be given a name. Anonymous namespaces will not work with diagnostics
local ns = vim.api.nvim_create_namespace("foo")
-- Generate diagnostics
local diagnostics = generate_diagnostics()
-- Set diagnostics for the current buffer
vim.diagnostic.set(ns, diagnostics, bufnr)
```
Some public facing API utility methods were removed and internalized directly in `vim.diagnostic`:
* `vim.lsp.util.diagnostics_to_items`
## API Design
`vim.diagnostic` contains most of the same API as `vim.lsp.diagnostic` with
`client_id` simply replaced with `namespace`, with some differences:
* Generally speaking, functions that modify or add diagnostics require a namespace as their first argument, e.g.
```lua
vim.diagnostic.set({namespace}, {bufnr}, {diagnostics}[, {opts}])
```
while functions that read or query diagnostics do not (although in many cases one may be supplied optionally):
```lua
vim.diagnostic.get({bufnr}[, {namespace}])
```
* We use our own severity levels to decouple `vim.diagnostic` from LSP. These
are designed similarly to `vim.log.levels` and currently include:
```lua
vim.diagnostic.severity.ERROR
vim.diagnostic.severity.WARN
vim.diagnostic.severity.INFO
vim.diagnostic.severity.HINT
```
In practice, these match the LSP diagnostic severity levels exactly, but we
should treat this as an interface and not assume that they are the same. The
"translation" between the two severity types is handled transparently in
`vim.lsp.diagnostic`.
* The actual "diagnostic" data structure is: (**EDIT:** Updated 2021-09-09):
```lua
{
lnum = <number>,
col = <number>,
end_lnum = <number>,
end_col = <number>,
severity = <vim.diagnostic.severity>,
message = <string>
}
```
This differs from the LSP definition of a diagnostic, so we transform them in
the handler functions in vim.lsp.diagnostic.
## Configuration
The `vim.lsp.with` paradigm still works for configuring how LSP diagnostics are
displayed, but this is a specific use-case for the `publishDiagnostics` handler.
Configuration with `vim.diagnostic` is instead done with the
`vim.diagnostic.config` function:
```lua
vim.diagnostic.config({
virtual_text = true,
signs = false,
underline = true,
update_in_insert = true,
severity_sort = false,
}[, namespace])
```
(or alternatively passed directly to `set()` or `show()`.)
When the `namespace` argument is `nil`, settings are set globally (i.e. for
*all* diagnostic namespaces). This is what user's will typically use for their
local configuration. Diagnostic producers can also set configuration options for
their specific namespace, although this is generally discouraged in order to
respect the user's global settings. All of the values in the table passed to
`vim.diagnostic.config()` are resolved in the same way that they are in
`on_publish_diagnostics`; that is, the value can be a boolean, a table, or
a function:
```lua
vim.diagnostic.config({
virtual_text = function(namespace, bufnr)
-- Only enable virtual text in buffer 3
return bufnr == 3
end,
})
```
## Misc Notes
* `vim.diagnostic` currently depends on `vim.lsp.util` for floating window
previews. I think this is okay for now, although ideally we'd want to decouple
these completely.
Port VimL's Blob type - vim-patch:8.1.{0735,0736,0738,0741,0742,0755,0756,0757,0765,0793,0797,0798,0802,1022,1023,1671},8.2.{0121,0184,0404,0521,0829,1473,1866,2712}
Note that it is not possible for msgpack_unpack_next() and
msgpack_unpacker_next() to return MSGPACK_UNPACK_EXTRA_BYTES, so it
should be fine to abort() on that.
Lua 5.1 doesn't support string hex escapes (\xXX) like VimL does (though
LuaJIT does), so convert them to decimal escapes (\DDD) in tests.
These were issues that I found while porting that I fixed upstream. :^)
Very little of the patch can be exactly ported as we're a bit behind on
dependant patches (we also can't use the exact :for emsg, as we don't
support iterating over Strings yet), so just translate the fixes as best
as we can for now.
Include latest relevant doc changes from:
- v8.1.0815
- v8.2.2658
Fixes remove() copying one extra byte after the end of a Blob's buffer.
Can't be fully ported as the change is from blob_remove(), which hasn't
been ported yet.
Problem: Items in a list given to :const can still be modified.
Solution: Work like ":lockvar! name" but don't lock referenced items.
Make locking a blob work.
021bda5671
Problem: filter() may give misleading error message.
Solution: Also mention Blob as an allowed argument.
fcb0b61d15
Rename Test_map_fails() to Test_map_filter_fails() from v8.2.0610 and
include the modeline.
Problem: Crash when reading a blob fails.
Solution: Avoid keeping a pointer to a freed blob object. (Dominique Pelle,
closesvim/vim#5890) Adjust error messages.
15352dc6ec
Problem: Blob test fails.
Solution: Check for different error when float feature is missing.
92be6e3f46
Nvim always has the float feature, but include the changes to the test
anyway.
Problem: Negative index doesn't work for Blob.
Solution: Make it work, add a test. (closesvim/vim#3856)
a5be9b6248
Leave tv_blob_get()'s return type untouched.
Problem: Incorrect error messages for functions that now take a Blob
argument.
Solution: Adjust the error messages. (Dominique Pelle, closesvim/vim#3846)
0d17f0d1c0
Problem: Using freed memory, for loop over blob leaks memory.
Solution: Clear pointer after freeing memory. Decrement reference count
after for loop over blob.
ecc8bc482b
Strings that previously decoded into a msgpack special for representing
BINs with NULs now convert to Blobs. It shouldn't be possible to decode
into this special anymore after this change?
Notably, Lua strings with NULs now convert to Blobs when passed to VimL.
As Strings and Blobs are encoded as msgpack BINs, the current ShaDa
implementation will restore global Blob variables as Strings (or msgpack
special dicts if they contain NULs).
Encode an additional element with Blob globals to differentiate them
from Strings so that we can restore them with the correct type.
Adjust variables_spec.lua's autotest() to also check for proper type.
Problem: Code for Blob not sufficiently tested.
Solution: Add more tests. Fix uncovered crash. Add test_null_blob().
c0f5a78c15
eval0 and ex_echo's emsg-specific changes have already been ported.
These tests uncover another crash that was fixed in v8.1.0738.
Problem: Cannot handle binary data.
Solution: Add the Blob type. (Yasuhiro Matsumoto, closesvim/vim#3638)
6e5ea8d2a9
Nvim-specific Blob conversions are implemented in future commits.
Refactor write_blob() to use a FileDescriptor, as f_writefile() was
refactored to use one (does not apply to read_blob()).
Use var_check_lock() in f_add() for Blobs from v8.1.0897.
Add a modeline to test_blob.vim and fix some doc typos.
Include if_perl.txt's VIM::Blob() documentation. Interestingly, this
function already worked before this port, as it just returns a Blob
string literal, not an actual Blob object.
N/A patches for version.c:
vim-patch:8.1.0741: viminfo with Blob is not tested
Problem: Viminfo with Blob is not tested.
Solution: Extend the viminfo test. Fix reading a blob. Fixed storing a
special variable value.
8c8b8bb56c
vim-patch:8.1.1022: may use NULL pointer when out of memory
Problem: May use NULL pointer when out of memory. (Coverity)
Solution: Check for blob_alloc() returning NULL.
e142a9467a
This generalizes diagnostic handling outside of just the scope of LSP.
LSP clients are now a specific case of a diagnostic producer, but the
diagnostic subsystem is decoupled from the LSP subsystem (or will be,
eventually).
More discussion at [1].
[1]: https://github.com/neovim/neovim/pull/15585
It's possible for weirdness to happen if curbuf is modified while
sourcing from it via :source (with no arguments). For example:
- Deleting lines from or wiping curbuf can cause internal error E315 to
be thrown from ml_get.
- Changing the curbuf to another buffer while sourcing can cause lines
from the new curbuf to then be sourced instead.
Problem:
Anonymous :source (no args) and nvim_exec() don't support Vimscript line continuations.
Solution:
Factor out the concat logic into concat_continued_line() and a
CONCAT_CONTINUED_LINES macro for simple concatenations where lines are
fetched individually.
Closes#14807
Example assertion failure:
%0 in logmsg neovim/src/nvim/log.c:139:17
%1 in ui_call_update_menu neovim/build/src/nvim/auto/ui_events_call.generated.h:8:3
%2 in ex_menu neovim/src/nvim/menu.c:263:3
%3 in do_one_cmd neovim/src/nvim/ex_docmd.c:1981:5
%4 in do_cmdline neovim/src/nvim/ex_docmd.c:602:20
%5 in do_cmdline_cmd neovim/src/nvim/ex_docmd.c:287:10
%6 in free_all_mem neovim/src/nvim/memory.c:596:3
%7 in os_exit neovim/src/nvim/main.c:574:3
%8 in exit_event neovim/src/nvim/msgpack_rpc/channel.c:569:5
