Problem:
Some built-in ftplugins set omnifunc/tagfunc/formatexpr which causes
lsp.lua:set_defaults() to skip setup of defaults for those filetypes.
For example the C++ ftplugin has:
omnifunc=ccomplete#Complete
Last set from /usr/share/nvim/runtime/ftplugin/c.vim line 30
so the changes done in #95c65a6b221fe6e1cf91e8322e7d7571dc511a71
will always be skipped for C++ files.
Solution:
Overwrite omnifunc/tagfunc/formatexpr options that were set by stock
ftplugin.
Fixes#21001
Problem:
:Man command errors if given more than two arguments. Thus, it is
impossible to open man pages that contain spaces in their names.
Solution:
Adjust :Man so that it tries variants with spaces and underscores, and
uses the first found.
feat(lsp)!: change semantic token highlighting
Change the default highlights used, and add more highlights per token.
Add an LspTokenUpdate event and a highlight_token function.
:Inspect now shows any highlights applied by token highlighting rules,
default or user-defined.
BREAKING CHANGE: change the default highlight groups used by semantic
token highlighting.
redraw! redraws the entire screen instead of just the windows with
the buffer which were actually changed.
I considered trying to calculating the range for the delta
but it looks tricky. Could a follow-up.
`vim.lsp.buf.format()` silently did nothing if no servers supported
`textDocument/rangeFormatting` when formatting with a range.
Issue found by `@hwrd:matrix.org` in the Matrix chat.
Rather than only check `editorconfig_enable` when the plugin is loaded,
check it each time the autocommand fires, so that users may enable or
disable it dynamically.
Also check for a buffer local version of the variable, so that
editorconfig can be enabled or disabled per-buffer.
This is the first PR featuring a conversion of an upstream vim9script file
into a Lua file.
The generated file can be found in `runtime/autoload/ccomplete.vim` in
the vim repository. Below is a limited history of the changes of that file
at the time of conversion.
```
❯ git log --format=oneline runtime/autoload/ccomplete.vim
c4573eb12dba6a062af28ee0b8938d1521934ce4 Update runtime files
a4d131d11052cafcc5baad2273ef48e0dd4d09c5 Update runtime files
4466ad6baa22485abb1147aca3340cced4778a66 Update runtime files
d1caa941d876181aae0ebebc6ea954045bf0da24 Update runtime files
20aac6c1126988339611576d425965a25a777658 Update runtime files.
30b658179962cc3c9f0a98f071b36b09a36c2b94 Updated runtime files.
b6b046b281fac168a78b3eafdea9274bef06882f Updated runtime files.
00a927d62b68a3523cb1c4f9aa3f7683345c8182 Updated runtime files.
8c8de839325eda0bed68917d18179d2003b344d1 (tag: v7.2a) updated for version 7.2a
...
```
The file runtime/lua/_vim9script.lua only needs to be updated when vim9jit is updated
(for any bug fixes or new features, like implementing class and interface, the latest in vim9script).
Further PRs will improve the DX of generated the converted lua and
tracking which files in the neovim's code base have been generated.
Currently once you retrieve the lenses you're pretty much stuck with
them as saving new lenses is additive.
Adding a dedicated method to reset lenses allows users to toggle lenses
on/off which can be useful for language servers where they are noisy or
expensive and you only want to see them temporary.
Apply semantic token modifiers as separate extmarks with corresponding
highlight groups (e.g., `@readonly`). This is a low-effort PR to enable
the most common use cases (applying, e.g., italics or backgrounds on top
of type highlights; language-specific fallbacks like `@global.lua` are
also available). This can be replaced by more complicated selector-style
themes later on.
Instead of testing for every possible modifier type, only test bits up
to the highest set in the token array. Saves many bit ops and
comparisons when there are no modifiers or when the highest set bit is a
lower bit than the highest possible in the legend on average.
Can be further simplified when non-luaJIT gets the full bit module (see #21222)
The spec indicates that the response may be `null`, but it doesn't
really say what a `null` response means. Since neovim raises an error if
the response is `null`, I figured that ignoring it would be the safest
bet.
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
1. The algorithm for applying edits was slightly incorrect. It needs to
preserve the original token list as the edits are applied instead of
mutating it as it iterates. From the spec:
Semantic token edits behave conceptually like text edits on
documents: if an edit description consists of n edits all n edits are
based on the same state Sm of the number array. They will move the
number array from state Sm to Sm+1.
2. Schedule the semantic token engine start() call in the
client._on_attach() function so that users who schedule_wrap() their
config.on_attach() functions (like nvim-lspconfig does) can still
disable semantic tokens by deleting the semanticTokensProvider from
their server capabilities.
* credit to @smolck and @theHamsta for their contributions in laying the
groundwork for this feature and for their work on some of the helper
utility functions and tests
`willSaveWaitUntil` allows servers to respond with text edits before
saving a document. That is used by some language servers to format a
document or apply quick fixes like removing unused imports.
Extend the capabilities of is_os to detect more platforms such as
freebsd and openbsd. Also remove `iswin()` helper function as it can be
replaced by `is_os("win")`.
This is essentially a convenience wrapper around the `pending()`
function, similar to `skip_fragile()` but more general-purpose.
Also remove `pending_win32` function as it can be replaced by
`skip(iswin())`.
- If Nvim was just started, don't create a new tab.
- Name the buffer "health://".
- Use "help" syntax instead of "markdown". It fits better, and
eliminates various workarounds.
- Simplfy formatting, avoid visual noise.
- Don't print a "INFO" status, it is noisy.
- Drop the ":" after statuses, they are already UPPERCASE and highlighted.
* fix(man): handle absolute paths as :Man targets
Previously, attempting to provide `:Man` with an absolute path as the name would
cause neovim to return the following error:
```
Error detected while processing command line:
/usr/local/share/nvim/runtime/lua/man.lua:690: /usr/local/share/nvim/runtime/lua/man.lua:683: Vim:E426: tag not found: nil(nil)
Press ENTER or type command to continue
```
..because it would try to validate the existence of a man page for the provided
name by executing `man -w /some/path` which (on at least some Linux machines
[0]) returns `/some/path` instead of the path to the nroff files that would be
formatted to satisfy the man(1) lookup.
While man pages are not normally named after absolute paths, users shouldn't be
blamed for trying. Given such a name/path, neovim would **not** complain that
the path didn't have a corresponding man file but would error out when trying
to call the tag function for the null-propagated name-and-section `nil(nil)`.
(The same underlying error existed before this function was ported to lua, but
did not exhibit the lua-specific `nil(nil)` name; instead a tag lookup for `()`
would fail and error out.)
With this patch, we detect the case where `man -w ...` returns the same value as
the provided name to not only prevent invoking the tag function for a
non-existent/malformed name+sect but also to properly report the non-existence
of a man page for the provided lookup (the absolute path).
While man(1) can be used to directly read an nroff-formatted document via `man
/path/to/nroff.doc`, `:Man /path/to/nroff.doc` never supported this behavior so
no functionality is lost in case the provided path _was_ an nroff file.
[0]: `man -w /absolute/path` returning `/absolute/path` observed on an Ubuntu
18.04 installation.
* test: add regression test for #20624
Add a functional test to `man_spec.lua` to check for a regression for #20624 by
first obtaining an absolute path to a random file and materializing it to disk,
then attempting to query `:Man` for an entry by that same name/path.
The test passes if nvim correctly reports that there is no man page
correspending to the provided name/path and fails if any other error (or no
error) is shown.
These tests contained errors due to synstack() and friends do not ensure
syntax state is fully synced. Actually expecting what the user will
see with a screen test does ensure it is fully synced.
`!did_throw` doesn't exactly imply `!current_exception`, as `did_throw = false`
is sometimes used to defer exception handling for later (without forgetting the
exception). E.g: uncaught exception handling in `do_cmdline()` may be deferred
to a different call (e.g: when `try_level > 0`).
In #7881, `current_exception = NULL` in `do_cmdline()` is used as an analogue of
`did_throw = false`, but also causes the pending exception to be lost, which
also leaks as `discard_exception()` wasn't used.
It may be possible to fix this by saving/restoring `current_exception`, but
handling all of `did_throw`'s edge cases seems messier. Maybe not worth
diverging over.
This fix also uncovers a `man_spec.lua` bug on Windows: exceptions are thrown
due to Windows missing `man`, but they're lost; skip these tests if `man` isn't
executable.
`:saveas newName` changes the name of an existing buffer.
Due to the buffer re-use it skips the lsp attach phase and immediately
sends a `didSave` notification to the server.
Servers get confused about this, because they expect a `didOpen`
notification first.
Closes https://github.com/neovim/neovim/issues/18688
This fixes the following bugs:
`${1:else_text}` -> format with if_text: "else_text"
`${1:-else_text}` -> format with if_text: "else_text"
`${1:}` in `format` (eg. empty else_text) -> error.
`${1:}` (eg. empty placeholder) -> error.
Thanks hrsh7th :)
Most LSP servers require the notification to correctly load the
settings and for those who don't it doesn't cause any harm.
So far this is done in lspconfig, but with the addition of vim.lsp.start
it should be part of core.
Problem:
https://github.com/neovim/neovim/pull/18720#issuecomment-1142614996
The vim.health module is detected as a healthcheck, which produces spurious errors:
vim: require("vim.health").check()
========================================================================
- ERROR: Failed to run healthcheck for "vim" plugin. Exception:
function health#check, line 20
Vim(eval):E5108: Error executing lua [string "luaeval()"]:1: attempt to call field 'check' (a nil value)
stack traceback:
[string "luaeval()"]:1: in main chunk
Solution:
Skip vim.health when discovering healthchecks.
Cuts down typical run time for `plugin/lsp_spec.lua`
from 70 secs to 12 secs in ASAN CI build.
This happens in ASAN/EXIT_FREE builds where nvim waits 2000ms due to
unclosed handled. I wasn't able to pin-point the exact cause.
But these tests ran in nested context where two server/client pairs
were setup for no good reason. Moving these tests out so only one client
is being setup fixed the exit hang.
The current approach of using `on_attach` callbacks for configuring
buffers for LSP is suboptimal:
1. It does not use the standard Nvim interface for driving and hooking
into events (i.e. autocommands)
2. There is no way for "third parties" (e.g. plugins) to hook into the
event. This means that *all* buffer configuration must go into the
user-supplied on_attach callback. This also makes it impossible for
these configurations to be modular, since it all must happen in the
same place.
3. There is currently no way to do something when a client detaches from
a buffer (there is no `on_detach` callback).
The solution is to use the traditional method of event handling in Nvim:
autocommands. When a LSP client is attached to a buffer, fire a
`LspAttach`. Likewise, when a client detaches from a buffer fire a
`LspDetach` event.
This enables plugins to easily add LSP-specific configuration to buffers
as well as enabling users to make their own configurations more modular
(e.g. by creating multiple LspAttach autocommands that each do
something unique).
Problem:
q in "$MANPAGER mode" does not quit Nvim. This is because
ftplugin/man.vim creates its own mapping:
nnoremap <silent> <buffer> <nowait> q :lclose<CR><C-W>c
which overrides the one set by the autoload file when using :Man!
("$MANPAGER mode")
Solution:
Set b:pager during "$MANPAGER mode" so that ftplugin/man.vim can set the
mapping correctly.
Fixes#18281
Ref #17791
Helped-by: Gregory Anders <8965202+gpanders@users.noreply.github.com>
Implement filtering of actions based on the kind when passing the 'only'
parameter to code_action(). Action kinds are hierachical with a '.' as
the separator, and the filter thus allows, for example, both 'quickfix'
and 'quickfix.foo' when requestiong only 'quickfix'.
Fix https://github.com/neovim/neovim/pull/18221#issuecomment-1110179121
Adds filter and id options to filter the client to use for rename.
Similar to the recently added `format` function.
rename will use all matching clients one after another and can handle a
mix of prepareRename/rename support. Also ensures the right
`offset_encoding` is used for the `make_position_params` calls
This fixes issues where subsequent calls to vim.lsp.codelens.refresh()
would have no effect due to the buffer not getting cleared from the
active_refresh table.
Examples of how such scenarios would occur are:
- A textDocument/codeLens result yielded an error.
- The 'textDocument/codeLens' handler was overriden in such a way that
it no longer called vim.lsp.codelens.on_codelens().
Deprecates the existing `vim.lsp.buf.formatting` function.
With this, `vim.lsp.buf.format` will replace all three:
- vim.lsp.buf.formatting
- vim.lsp.buf.formatting_sync
- vim.lsp.buf.formatting_seq_sync
* feat(lsp)!: remove capabilities sanitization
Users must now access client.server_capabilities which matches the same
structure as the protocol.
https://microsoft.github.io/language-server-protocol/specification
client.resolved_capabilities is no longer used to gate capabilities, and
will be removed in a future release.
BREAKING CHANGE
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
Implement two new options to vim.lsp.buf.code_action():
- filter (function): predicate taking an Action as input, and returning
a boolean.
- apply (boolean): when set to true, and there is just one remaining
action (after filtering), the action is applied without user query.
These options can, for example, be used to filter out, and automatically
apply, the action indicated by the server to be preferred:
vim.lsp.buf.code_action({
filter = function(action)
return action.isPreferred
end,
apply = true,
})
Fix#17514.
Some language servers send empty `textDocument/publishDiagnostics`
messages after indexing the project with URIs corresponding to unopened buffers.
This commit guards against opening buffers corresponding to empty diagnostics.
The use of 'softtabstop' to set tabSize was introduced in 5d5b068,
replacing 'tabstop'. If we look past the name tabSize and at the actual
purpose of the field, it's the indentation width used when formatting.
This corresponds to the Vim option 'shiftwidth', not 'softtabstop'.
The latter has the comparatively mundane purpose of controlling what
happens when you hit the tab key (and even this is incomplete, as it
fails to account for 'smarttab').
This removes the "fallback" to utf-16 in many of our helper functions. We
should always explicitly pass these around when possible except in two
locations:
* generating params with help utilities called by buf.lua functions
* the buf.lua functions themselves
Anything that is called by the handler should be passed the offset encoding.
omnisharp-roslyn can send negative values:
{
activeParameter = 0,
activeSignature = -1,
signatures = { {
documentation = "",
label = "TestEntity.TestEntity()",
parameters = {}
} }
}
In 3.16 of the specification `activeSignature` is defined as `uinteger`
and therefore negative values shouldn't be allowed, but within 3.15 it
was defined as `number` which makes me think we can be a bit lenient in
this case and handle them.
The expected behavior is quite clear:
The active signature. If omitted or the value lies outside the
range of `signatures` the value defaults to zero or is ignored if
the `SignatureHelp` has no signatures.
Fixes an error:
util.lua:1685: attempt to get length of local 'lines' (a nil value)
util.lua:1685: in function 'trim_empty_lines'
handlers.lua:334: in function 'textDocument/signatureHelp'
Part of the `pending_change` closure in the `changetracking.prepare` was
a bit confusing because it has access to `bufnr` and `uri` but it could
actually contain pending changes batched for multiple buffers.
(We accounted for that by grouping `pending_changes` by a `uri`, but
it's not obvious what's going on)
This commit changes the approach to do everything per buffer to avoid
any ambiguity.
It also brings the debounce/no-debounce a bit closer together: The
only difference is now whether a timer is used or if it is triggered
immediately
This allows the user to detach an active buffer from the language
client. If no clients remain attached to a buffer, the on_lines callback
is used to cancel nvim_buf_attach.
Closes#16624
Fixes two issues with aligning the start position and end position to
codepoints when calculating the start and end range.
When aligning the start position:
* use aligned byte index to calculate character index rather than
the unadjusted byte
When aligning the end position:
* do not adjust the end byte if it falls on a UTF-8 codepoint
* align byte to the first byte of the next codepoint rather than the
last byte of the current codepoint
* compute character character end range on the aligned byte index
This commit also adds additional test coverage, including multibyte operations
that previously failed before this commit.
If a LSP server sent a workspace edit containing a rename the buffers
file name changed without the server receiving a close notification for
the old buffer and without the client properly re-attaching on the new
file.
This affected `Move` code-actions in nvim-jdtls, but also
`vim.lsp.buf.rename` on a class level.
* use codeunits/points instead of byte ranges when applicable
* take into account different file formats when computing range and
sending text (dos, unix, and mac supported)
* add tests of incremental sync
* vim.ui.input is an overridable function that prompts for user input
* take an opts table and the `on_confirm` callback, see `:help vim.ui.input` for more details
* defaults to a wrapper around vim.fn.input(opts)
* switches the built-in client's rename handler to use vim.ui.input by default
Rather than treating virtual_text, signs, and underline specially,
introduce the concept of generic "handlers", of which those three are
simply the defaults bundled with Nvim. Handlers are called in
`vim.diagnostic.show()` and `vim.diagnostic.hide()` and are used to
handle how diagnostics are displayed.
The runtime file update
2286304cdb
added a `syn keyword` for `css`, which affects (via `html` and
`markdown` syntax files) the highlighting of `:checkhealth` output
(before, `ERROR:` was highlighted with `healthError`; now the colon is
no longer included).
Closes https://github.com/neovim/neovim/issues/15174
Instead of invoking handlers with unsupported methods, pre-compute which
clients support a given method and only notify the user if no clients
support the given method.
* fix(runtime/health): mitigate issues with duplicate healthchecks
Previously if a healthcheck was found as Lua and Vim it was executed
both times.
This new implementations prefers Lua, therefore if two are found It only
runs the Lua one, this way a plugin can mantain both implementations the
Lua one with the method `check()` and the autoload function `#check()`
(for none HEAD nvim versions).
**Note: This will require plugins to use `check()` as the function name,
since the autoload function that wraps the lua implementation won't be
called**
* docs(health): use spaces and don't overuse backtics
followup to #15259
Move away from providing completion with ExpandRTDir to ExpandGeneric
providing the function get_healthcheck_name which caches the results for
the current command line prompt.
It does the almost the same thing the Vim function 'get_healthcheck'
implemented in 'runtime/autoload/health.vim' does.
- Add tests for lua healthchecks (failure, success and submodules).
- Reword some of the test naming for improved logs readability.
- Modify render test to accomodate the changes of the health autoload function.
- Add test for :checkhealth completion of Lua healtchecks.
N, W, S, E are all inclusive, i.e., always anchor to the exact corner of the
window (including border). This line may also need change in this case (change
0 to -1):
This is most consistent and easiest to reason about, especially with GUIs whose
border do not need to have width/height of 1/1 in cell units.
Fix#15789
* preserve fields from LSP diagnostics via adding a user_data table to the diagnostic, which can hold arbitrary data in addition to the lsp diagnostic information.
This is mostly motivated by https://github.com/neovim/neovim/issues/12326
Client side commands might need to access the original request
parameters.
Currently this is already possible by using closures with
`vim.lsp.buf_request`, but the global handlers so far couldn't access
the request parameters.
These links were actually defined backwards: the highlight groups
actually being used for display are the new "Diagnostic*" groups, so
linking the old "LspDiagnostics*" groups to these does absolutely
nothing, since there is nothing actually being highlighted with the
LspDiagnostics* groups.
These links were made in an attempt to preserve backward compatibility
with existing colorschemes. We could reverse the links to maintain this
preservation, but then that disallows us from actually defining default
values for the new highlight groups.
Instead, just remove the links and be done with the old LspDiagnostics*
highlight groups.
This is not technically a breaking change: the breaking change already
happened in #15585, but this PR just makes that explicit.
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
Previously, the handler signature was:
function(err, method, params, client_id, bufnr, config)
In order to better support external plugins that wish to extend the
protocol, there is other information which would be advantageous to
forward to the client, such as the original params of the request that
generated the callback.
In order to do this, we would need to break symmetry of the handlers, to
add an additional "params" as the 7th argument.
Instead, this PR changes the signature of the handlers to:
function(err, result, ctx, config)
where ctx (the context) includes params, client_id, and bufnr. This also leaves
flexibility for future use-cases.
BREAKING_CHANGE: changes the signature of the built-in client handlers, requiring
updating handler calls
Add two new methods to allow diagnostics to be disabled (and re-enabled)
in the current buffer. When diagnostics are disabled they are simply not
displayed to the user, but they are still sent by the server and
processed by the client.
Disabling diagnostics can be helpful in a number of scenarios. For
example, if one is working on a buffer with an overwhelming amount of
diagnostic warnings it can be helpful to simply disable diagnostics
without disabling the LSP client entirely. This also allows users more
flexibility on when and how they may want diagnostic information to be
displayed. For example, some users may not want to display diagnostic
information until after the buffer is first written.
This commit prevents two things regarding the tagstack and jumping to
locations:
- Pushing the same item twice in a row
- Pushing an item where the destination is the same as the source
Both prevent having to press CTRL-T additional times just to pop items
that don't make the cursor move.
There were a couple of reports of "Buffer X newer than edits" problems.
We first assumed that it is incorrect for a server to send 0 as a
version - and stated that they should send a `null` instead, given that
in the specification the `textDocument` of a `TextDocumentEdit` is a
`OptionalVersionedTextDocumentIdentifier`.
But it turns out that this was a change in 3.16, and in 3.15 and earlier
versions of the specification it was a `VersionedTextDocumentIdentifier`
and language servers didn't have a better option than sending `0` if
they don't keep track of the version numbers.
So this changes the version check to always accept `0` values.
See
- https://github.com/neovim/neovim/issues/12970
- https://github.com/neovim/neovim/issues/14256
- https://github.com/haskell/haskell-language-server/pull/1727
before, calling vim.schedule() from inside an event would execute
the scheduled callback immediately after this event without
checking for user input in between. Break event processing
whenever user input or an interrupt is available.
* lsp: client stop cleanups
* Add diagnostic clearing to client.stop() method used by nvim-lspconfig
* Clear diagnostic cache to prevent stale diagnostics on client restart
* lsp: Add test for vim.lsp.diagnostic.reset
The `workspace/configuration` handler could fail with the following
error if `config.settings` is nil:
runtime/lua/vim/lsp/util.lua:1432: attempt to index local 'settings' (a nil value)"
This ensures that `config.settings` is always initialized to an empty
table.
* lsp: Remove duplicate `diagnostics` fallback in diagnostic.display
* lsp: Expose all diagnostics
Before the changes in #12655 it was possible to retrieve all diagnostics
via `vim.lsp.util.diagnostics_by_buf`.
This adds a `diagnostic.get_all()` to enable users to retrieve all
diagnostics.
Use cases for that could include loading all diagnostics into the
quickfix list, or to build an enhanced goto_next that can move across
buffers.
Breaking Changes:
- Deprecated all `vim.lsp.util.{*diagnostics*}()` functions.
- Instead, all functions must be found in vim.lsp.diagnostic
- For now, they issue a warning ONCE per neovim session. In a
"little while" we will remove them completely.
- `vim.lsp.callbacks` has moved to `vim.lsp.handlers`.
- For a "little while" we will just redirect `vim.lsp.callbacks` to
`vim.lsp.handlers`. However, we will remove this at some point, so
it is recommended that you change all of your references to
`callbacks` into `handlers`.
- This also means that for functions like |vim.lsp.start_client()|
and similar, keyword style arguments have moved from "callbacks"
to "handlers". Once again, these are currently being forward, but
will cease to be forwarded in a "little while".
- Changed the highlight groups for LspDiagnostic highlight as they were
inconsistently named.
- For more information, see |lsp-highlight-diagnostics|
- Changed the sign group names as well, to be consistent with
|lsp-highlight-diagnostics|
General Enhancements:
- Rewrote much of the getting started help document for lsp. It also
provides a much nicer configuration strategy, so as to not recommend
globally overwriting builtin neovim mappings.
LSP Enhancements:
- Introduced the concept of |lsp-handlers| which will allow much better
customization for users without having to copy & paste entire files /
functions / etc.
Diagnostic Enhancements:
- "goto next diagnostic" |vim.lsp.diagnostic.goto_next()|
- "goto prev diagnostic" |vim.lsp.diagnostic.goto_prev()|
- For each of the gotos, auto open diagnostics is available as a
configuration option
- Configurable diagnostic handling:
- See |vim.lsp.diagnostic.on_publish_diagnostics()|
- Delay display until after insert mode
- Configure signs
- Configure virtual text
- Configure underline
- Set the location list with the buffers diagnostics.
- See |vim.lsp.diagnostic.set_loclist()|
- Better performance for getting counts and line diagnostics
- They are now cached on save, to enhance lookups.
- Particularly useful for checking in statusline, etc.
- Actual testing :)
- See ./test/functional/plugin/lsp/diagnostic_spec.lua
- Added `guisp` for underline highlighting
NOTE: "a little while" means enough time to feel like most plugins and
plugin authors have had a chance to refactor their code to use the
updated calls. Then we will remove them completely. There is no need to
keep them, because we don't have any released version of neovim that
exposes these APIs. I'm trying to be nice to people following HEAD :)
Co-authored: [Twitch Chat 2020](https://twitch.tv/teej_dv)
Refactors how required capabilities are detected and validated, and make
sure requests are only sent to clients that support it (and only fail if
no clients support the provided method).
The validation happens at the buf_request level, because we assume that
if someone is sending the request directly through the client, they know
what they're doing. Also, let unknown methods go through.
This is extracted from #12518 and closes#12755.
Co-authored-by: francisco souza <fsouza@users.noreply.github.com>
- The previous commit lost information in the tests. Instead, add some
more "normalization" substitutions in pcall_err(), so that the general
shape of the stacktrace is included in the asserted text.
- Eliminate contains(), it is redundant with matches()
* LSP: Add support for call hierarchies
* LSP: Add support for call hierarchies
* LSP: Add support for call hierarchies
* LSP: Jump to call location
Jump to the call site instead of jumping to the definition of the
caller/callee.
* LSP: add tests for the call hierarchy callbacks
* Fix linting error
Co-authored-by: Cédric Barreteau <>
* LSP: Add tests & use nvim_buf_get_lines in locations_to_items
This is to add support for cases where the server returns a URI in the
locations that does not have a file scheme but needs to be loaded via a
BufReadCmd event.
* LSP: Don't iterate through all lines in locations_to_items
* fixup! LSP: Don't iterate through all lines in locations_to_items
* fixup! fixup! LSP: Don't iterate through all lines in locations_to_items
* fixup! fixup! fixup! LSP: Don't iterate through all lines in locations_to_items
* lsp: support custom hl groups in show_line_diagnostics
Closes#12472.
* runtime: add docs for the new lsp highlight groups
Co-authored-by: francisco souza <fsouza@users.noreply.github.com>
According to the LSP spec[1], multiple edits can have the same starting
position, and if that is the case, they should be applied in the order
as they come in the array.
The implementation uses a reverse sort to not interfere with non applied
edits, but failed to take into account the spec.
[1] https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#textedit
* take wrapping into account when computing float height
* factor out size calculation
* add test
* accept and pass through opts.wrap_at in floating_preview
* make padding configurable
* slightly refactor fancy_floating_markdown to make use of make_position
* padding using string.format
* move trim and pad to separate function
* nit
Co-authored-by: Hirokazu Hata <h.hata.ai.t@gmail.com>
* remove mention of backward compat
* make lint happy
Co-authored-by: Hirokazu Hata <h.hata.ai.t@gmail.com>
Old behavior is: foo(${placeholder: bar, ...)
with lots of random garbage you'd never want inserted.
New behavior is: foo(bar, baz)
(which maybe is good, maybe is bad [depends on user], but definitely better than it was).
-----
* Implement rudimentary snippet parsing
Add support for parsing and discarding snippet tokens from the completion items.
Fixes#11982
* Enable snippet support
* Functional tests for snippet parsing
Add simplified real-world snippet text examples to the completion items
test
* Add a test for nested snippet tokens
* Remove TODO comment
* Return the unmodified item if the format is plain text
* Add a plain text completion item
If the LSP sends an end line that is larger than what nvim considers to be the
last line, you get an Index out of bounds error when fetching the line from
nvim, a change that was introduced in #12223. This change removes the strict
indexing and checks the return value from nvim_buf_get_lines.
* Make apply_text_edits non-ASCII safe
Use `vim.str_byteindex` to correct starting and ending positions for text edits if the line contains non-ASCII characters.
Fixes#12221
* text_edit may be applied to other buffers
* make sure the buffer is loaded
* add comments
* add test for non-ASCII edits
* lsp: handle kinds not specified in protocol
fix: #12200
If the client set "symbolKind.valueSet",
the client must handle it properly even if it receives a value outside the specification.
* test: add lsp.util.{get_completion_item_kind_name, get_symbol_kind_name} test case
* lsp: make lsp.util.{get_completion_item_kind_name, get_symbol_kind_name} private
lsp.util.buf_versions must be set in advance.
Use helper.insert to create an anonymous buffer,
so create a named buffer for testing without using insert.
This commit creates 4 new highlight groups:
- LspDiagnosticsErrorSign
- LspDiagnosticsWarningSign
- LspDiagnosticsInformationSign
- LspDiagnosticsHintSign
These highlight groups are linked to their corresponding LspDiagnostics
highlight groups by default.
This lets users choose a different color for their sign columns and
virtualtext diagnostics.
Expose `vim.lsp.buf.diagnostics_by_buf`
This makes it easier to customize the diagnostics behavior. For example
to defer the update they can override the
`textDocument/publishDiagnostics` callback to only call
`buf_diagnostics_save_positions` and then defer the other actions to a
autocmd event.
- os.exit(1) is too generic, since code 1 may be caused by Nvim exiting
for some other reason. Change it to os.exit(101).
- style: de-architect json_encode/json_decode calls.
Failure seen in travis macOS job:
https://travis-ci.org/neovim/neovim/jobs/647849133
[ FAILED ] test/functional/plugin/lsp_spec.lua@ 266 SP basic_init test should not send didOpen if the buffer closes before init
test/functional/plugin/lsp_spec.lua:297: exit code
Expected objects to be the same.
Passed in:
(number) 1
Expected:
(number) 0
stack traceback:
test/functional/plugin/lsp_spec.lua:297: in function 'on_exit'
test/functional/plugin/lsp_spec.lua💯 in function 'test_rpc_server'
test/functional/plugin/lsp_spec.lua:272: in function <test/functional/plugin/lsp_spec.lua:266>
Reduce API surface. We don't need so many variations of functions. Too
many functions means verbose, largely redundant documentation, tests,
and cognitive burden.
- Use correct implementation of text_edits.
- Send indent options to rangeFormatting and formatting.
- Remove references to vim bindings and filetype from lsp.txt
- Add more examples to docs.
- Add before_init to allow changing initialize_params.
Mainly configuration and RPC infrastructure can be considered "done". Specific requests and their callbacks will be improved later (and also served by plugins). There are also some TODO:s for the client itself, like incremental updates.
Co-authored by at-tjdevries and at-h-michael, with many review/suggestion contributions.
It is perfectly fine and expected to detach from the screen just by
the UI disconnecting from nvim or exiting nvim. Just keep detach() in
screen_basic_spec, to get some coverage of the detach method itself.
This avoids hang on failure in many situations (though one could argue
that detach() should be "fast", or at least "as fast as resize",
which works in press-return already).
Never use detach() just to change the size of the screen, try_resize()
method exists for that specifically.
Doing clear() multiple times in quick succession provokes the
`exit_event` race described in #8813.
- Avoid it by removing unnecessary reset() call.
- Replace unnecessary nested describe() blocks with it() blocks.
ref d4a0b6c4e1
luassert uses 3 by default, which is often not enough.
Instead of documenting how to increase it, let's use a more fitting
(sane) default of 100 levels.
The call to plugin_helpers.reset() is redundant with the clear() call
above it. Probably just a copy-paste mistake.
Avoids exit_event race #8813.
Helped-by: Björn Linse <bjorn.linse@gmail.com>
Give embeders a chance to set up nvim, by processing a request before
startup. This allows an external UI to show messages and prompts from
--cmd and buffer loading (e.g. swap files)
Lua (not LuaJIT) complains about the "^[[" strings inside the expect,
since it sees them as nested quotes. Change the quoting to [=[ ]=] to
avoid the issue.
Use unique filenames to avoid test conflicts.
Use read_file() instead of io.popen(), to ensures the file is closed.
Use helpers.rmdir(), it is far more robust than lfs.
closes#7911
`:syntax keyword` is affected by 'iskeyword'. When we aligned
'iskeyword' to that of filetype=help, colon (:) is now included.
Simplest way to deal with this is to include colon (:) in the `:syntax
keyword` directive.
Also:
- change "SUGGESTIONS" mouthful to "ADVICE"
- change "SUCCESS" to "OK"
Hope this will make people using feed_command less likely: this hides bugs.
Already found at least two:
1. msgpackparse() will show internal error: hash_add() in case of duplicate
keys, though it will still work correctly. Currently silenced.
2. ttimeoutlen was spelled incorrectly, resulting in option not being set when
expected. Test was still functioning somehow though. Currently fixed.
- Vim "unix default" of 'noshowcmd' is serving few users. And it's
inconsistent.
- 'ruler' and 'belloff=all' improve the out-of-the-box experience.
- Continue to use 'noshowcmd' and 'noruler' by default in the functional
tests to keep them fast.
TODO: Add a "disable slow stuff" command or mapping to address the
use-case of a very slow terminal connection.
