`code_action` gained extra functions (`filter` and `apply`) which
`range_code_action` didn't have.
To close this gap, this adds a `range` option to `code_action` and
deprecates `range_code_action`.
The option defaults to the current selection if in visual mode.
This allows users to setup a mapping like `vim.keymap.set({'v', 'n'},
'<a-CR>', vim.lsp.buf.code_action)`
`range_code_action` used to use the `<` and `>` markers to get the
_last_ selection which required using a `<Esc><Cmd>lua
vim.lsp.buf.range_code_action()<CR>` (note the `<ESC>`) mapping.
The LSP progress handler would put non-progress messages (such as from
clangd or pyls; not part of the LSP spec) directly into
`client.messages`, while `vim.lsp.util.get_progress_messages()` would
try to fetch them from `client.messages.messages` instead (and come up
empty everytime). This would result in these messages never being
cleaned up by `get_progress_messages()`.
This commit fixes that by treating those messages like show-once
progress messages (by setting `done=true` immediately).
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').
Closes https://github.com/neovim/neovim/issues/17456
* treesitter uses the default highlight priority of 50
* diagnostic highlights have a priority of 150
* lsp reference highlights have a priority of 200
This ensures proper ordering.
Closes https://github.com/neovim/neovim/issues/13647
This allows customizing the priority of the highlights.
* Add default priority of 50
* Use priority of 200 for highlight on yank
* use priority of 40 for highlight references (LSP)
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'
Closes https://github.com/neovim/neovim/issues/16985
* get_lines checks if buf_loaded using bufnr 0, which is
typically used as a sentinel value, but here must be resolved
to the true bufnr
As revealed by #16745, some functions pass a nil value to API functions,
which have been implicitly converted to 0. #16745 breaks this implicit
conversion, so explicitly pass a resolved buffer number to these API
functions.
Previously, the `_str_utfindex_enc` and `_str_byteindex_enc` helper functions would return `nil` when `offset_encoding == "utf-8"` and `index == nil`. Clearly, this doesn't reflect the expected behavior of the functions they're wrapping which would return the length of the line in this case. This should fix behavior with servers that use UTF-8 `offset_encoding` when applying text edits, formatting a range, and doing range code actions (though this isn't tested currently).
When buffer is visible in two splits simultaneously, BufHidden event is
not triggered, causing the floating window to remain on screen after
switching to another buffer.
Remove BufHidden event from close_events defaults, and close the window
if we changed the buffer to something other than the buffer that spawned
the floating window or the floating window buffer itself.
