Problem: the code and docs for vim.diagnostic.JumpOpts.float send mixed
signals about what the default should be. When the option is first set,
in the global_diagnostic_options table, the comment clearly says that
the default is false. Later in the code, in goto_diagnostic, there's
a line that sets the default to true if no default is present. Finally,
the docs say that the default is true.
Solution: Change the docs to reflect the new default of false and fix
the goto_diagnostic function.
Problem:
Error when calling vim.treesitter.start() and vim.treesitter.stop() in
init.lua.
Solution:
Ensure syntaxset augroup exists after loading synload.vim.
Although the built-in pum completion mechanism will filter anyway on the
next input it is odd if the initial popup shows entries which don't
match the current prefix.
Using fuzzy match on the label/prefix is compatible with
`completeopt+=fuzzy` and also doesn't seem to break postfix snippet
cases
Closes https://github.com/neovim/neovim/issues/29287
This is a breaking change which will make refactor of typval and shada
code a lot easier. In particular, code that would use or check for
v:msgpack_types.binary in the wild would be broken. This appears to be
rarely used in existing plugins.
Also some cases where v:msgpack_type.string would be used to represent a
binary string of "string" type, we use a BLOB instead, which is
vimscripts native type for binary blobs, and already was used for BIN
formats when necessary.
msgpackdump(msgpackparse(data)) no longer preserves the distinction
of BIN and STR strings. This is very common behavior for
language-specific msgpack bindings. Nvim uses msgpack as a tool to
serialize its data. Nvim is not a tool to bit-perfectly manipulate
arbitrary msgpack data out in the wild.
The changed tests should indicate how behavior changes in various edge
cases.
Problem: with a single `context.options` there is no way for user to
force which scope (local, global, both) is being temporarily set and
later restored.
Solution: replace single `options` context with `bo`, `go`, `wo`, and
`o`. Naming and implementation follows how options can be set directly
with `vim.*` (like `vim.bo`, etc.).
Options are set for possible target `win` or `buf` context.
Problem: `vim._with()` has many different use cases which are not
covered with tests.
Solution: cover with tests. Some (many) test cases are intentionally
marked as "pending" because they cover cases which don't work as
expected at the moment (and fixing them requires specific knowledge of
C codebase). Use them as a reference for future fixes.
Also some of "can be nested" tests currently might pass only because
the tested context doesn't work.
Instead of looping over all captured nodes, just take the end range from
the last node in the list. This uses the fact that nodes returned by
iter_matches are ordered by their range (earlier to later).
Problem: Treesitter highlighter clears the already populated highlight
state when performing spell checking while drawing a
smoothscrolled topline.
Solution: Save and restore the highlight state in the highlighter's
_on_spell_nav callback.
Problem: filetype: .envrc & .prettierignore not recognized
Solution: Detect '.envrc' as shell and '.prettierignore' as gitignore
filetype (Tyler Miller)
Support ft detection for `.envrc` files used by direnv, and
`.prettierignore` files used by prettier.
closes: vim/vim#15053resolves: neovim/neovim#2940549012cd8c2
Co-authored-by: Tyler Miller <tmillr@proton.me>
Problem:
`o`-ing on a folded line opens the fold, because the new line gets the
fold level from the above line (level '='), which extends the fold to
the new line. `O` has a similar problem when run on the line below a
fold.
Solution:
Use -1 for the added line to get the lower level from the above/below
line.
Problem:
If there are errors in the last line of a buffer, something like `Gdk` or
`G2k3J` will produce an error (at least with `lua_ls`):
Error executing vim.schedule lua callback:
.../neovim/share/nvim/runtime/lua/vim/diagnostic.lua:1446: Invalid 'line': out of range
Solution:
Only set extmarks if the target buffer line still exists
Problem: A custom 'statuscolumn' needs to check a bunch of options and
placed signs to replicate the default number column.
Solution: Rework %l item to include the necessary logic to mimic the
default number column. Remove now redundant %r item.
Problem: Vim-script files may not be recognised
Solution: Add shebang line detection (Doug Kearns)
closes: vim/vim#150120d4d23dac0
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem:
When 'ignorecase' is set, the default keymap Q and Q would exit visual
mode.
This issue was raised in #28287 and a fix was applied in #28289.
However, `==` operator is subject to user `ignorecase` setting.
Solution:
Switching to `==#` operator would guarantee case sensitive comparison
between visual mode and linewise visual mode.
Co-authored-by: Kuanju Chen <kuanju.chen@mksinst.com>
Co-authored-by: Ilia Choly <ilia.choly@gmail.com>
Co-authored-by: Jose Pedro Oliveira <jose.p.oliveira.oss@gmail.com>
Co-authored-by: Maria José Solano <majosolano99@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem:
For snippets lsp.completion prefers the label if it is shorter than the
insertText or textEdit to support postfix completion cases but clangd
adds decoration characters to labels. E.g.: `•INT16_C(c)`
Solution:
Use parse_snippet on insertText/textEdit before checking if it is
shorter than the label.
Fixes https://github.com/neovim/neovim/issues/29301
This reduces the number of nil checks around buf_versions usage
Test changes were lifted from 5c33815
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
this only changes the error message, so that it is clear that
the error is with the LSP server, rather than being a crash inside
nvim runtime scripts. We are already doing a lot of validation,
it's just that nil was being overlooked here.
This fixes issue #27395
Problem: the previous documentation falsely states that "v" always
refers to the start of a visual area. In fact, the reference of "v" and
"." complement each other. If the cursor is at the start of
a (characterwise) visual area, then "v" refers to the end of the area.
Solution: be more verbose and explicit about the connection between "."
and "v" and also refer to |v_o| which many vim users will be familiar
with for visual areas.
210b39c2d6
Co-authored-by: Peter Aronoff <peter@aronoff.org>
This change fixes an issue where glob patterns like `{a,ab}` would not
match `ab` because the first option `a` matches, then the end of the
string is expected but `b` is found, and LPeg does not backtrack to try
the next option `ab` which would match. The fix here is to also append
the rest of the pattern to the generated LPeg pattern for each option.
This changes a glob `{a,ab}` from being parsed as
("a" or "ab") "end of string"
to
("a" "end of string" or "ab" "end of string")
Here, matching against `ab` would try the first option, fail to match,
then proceed to the next option, and match.
The sacrifice this change makes is dropping support for nested `{}`
conditions, which VSCode doesn't seem to support or test AFAICT.
Fixes#28931
Co-authored-by: Sergey Slipchenko <faergeek@gmail.com>
It's a function to perform operations in their own sealed context,
similar to pythons `with`. This helps ease operations where you need to
perform an operation in a specific context, and then restore the
context.
Marked as private for now as it's not ready for public use. The current
plan is to start using this internally so we can discover and fix any
problems. Once this is ready to be exposed it will be renamed to
`vim.with`.
Usage:
```lua
local ret = vim._with({context = val}, function()
return "hello"
end)
```
, where `context` is any combination of:
- `buf`
- `emsg_silent`
- `hide`
- `horizontal`
- `keepalt`
- `keepjumps`
- `keepmarks`
- `keeppatterns`
- `lockmarks`
- `noautocmd`
- `options`
- `sandbox`
- `silent`
- `unsilent`
- `win`
(except for `win` and `buf` which can't be used at the same time). This
list will most likely be expanded in the future.
Work on https://github.com/neovim/neovim/issues/19832.
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
Problem:
Text edits with the same position (both line and character) were being
reverse sorted prior to being applied which differs from the lsp spec
Solution:
Change the sort order for just the same position edits
* Revert "fix(lsp): account for changedtick version gap on modified reset (#29170)"
This reverts commit 2e6d295f79.
* Revert "refactor(lsp): replace util.buf_versions with changedtick (#28943)"
This reverts commit 5c33815448.
Problem: Cannot have buffer-local value for 'completeopt'
(Nick Jensen).
Solution: Make 'completeopt' global-local (zeertzjq).
Also for some reason test Test_ColonEight_MultiByte seems to be failing
sporadically now. Let's mark it as flaky.
fixes: vim/vim#5487closes: vim/vim#14922529b9ad62a
We currently check $COLORTERM in the TUI process to determine if the
terminal supports 24 bit color (truecolor). If $COLORTERM is "truecolor"
or "24bit" then we automatically assume that the terminal supports
truecolor, but if $COLORTERM is set to any other value we still query
the terminal.
The `rgb` flag of the UI struct is a boolean which only indicates
whether the UI supports truecolor, but does not have a 3rd state that we
can use to represent "we don't know if the UI supports truecolor". We
currently use `rgb=false` to represent this "we don't know" state, and
we use XTGETTCAP and DECRQSS queries to determine at runtime if the
terminal supports truecolor. However, if $COLORTERM is set to a value
besides "truecolor" or "24bit" (e.g. "256" or "16) that is a clear
indication that the terminal _does not_ support truecolor, so it is
incorrect to treat `rgb=false` as "we don't know" in that case.
Instead, in the TUI process we only check for the terminfo capabilities.
This must be done in the TUI process because we do not have access to
this information in the core Neovim process when `_defaults.lua` runs.
If the TUI cannot determine truecolor support from terminfo alone, we
set `rgb=false` to indicate "we don't know if the terminal supports
truecolor yet, keep checking". When we get to `_defaults.lua`, we can
then check $COLORTERM and only query the terminal if it is unset.
This means that users can explicitly opt out of truecolor determination
by setting `COLORTERM=256` (or similar) in their environment.
Problem: no fuzzy-matching support for insert-completion
Solution: enable insert-mode completion with fuzzy-matching
using :set completopt+=fuzzy (glepnir).
closes: vim/vim#14878a218cc6cda
Co-authored-by: glepnir <glephunter@gmail.com>
LspDetach is now triggered by the main on_detach callback that is added
when an LSP client is attached to a buffer. The semantic_tokens module
already includes a LspDetach handler that does the right thing. When the
LspDetach trigger was added to the main LSP on_detach, it created a race
condition in semantic tokens when a buffer was deleted that would
trigger both its own on_detach and the LspDetach handlers. If the former
came last, an error was thrown trying to delete a non-existent augroup
(destroy() was being called twice).
Problem: no whitespace padding in commentstring option in ftplugins
Solution: Change default to include whitespace padding, update
existing filetype plugins with the new default value
(Riley Bruins)
closes: vim/vim#148430a0830624a
Co-authored-by: Riley Bruins <ribru17@hotmail.com>
Problem: Completion side effects not working randomly.
Solution: When creating the table of LSP responses, the table index
was used, but this is not the same as the actual client_id, so it was changed
to use the client_id directly.
Problem: filetype: rasi files are not recognized
Solution: regonize '*.rasi' files as rasi filetype,
include a filetype and syntax plugin
(Pierrick Guillaume)
ported from: https://github.com/Fymyte/rasi.vimcloses: vim/vim#14821280e5b13ca
Co-authored-by: Pierrick Guillaume <pierguill@gmail.com>
`lsp.util.buf_versions` was already derived from changedtick (`on_lines`
from `buf_attach` synced the version)
As far as I can tell there is no need to keep track of the state in a
separate table.
The `complete()` mechanism matches completion candidates against
the typed text, so strict pre-filtering isn't necessary.
This is a first step towards supporting postfix snippets (like
`items@insert` in luals)
Problem: When an lsp client is stopped, the client will
only clear the diagnostics for the attached buffers but
not the unattached buffers.
Solution: Reset the diagnostics for the whole namespace rather than
for only the attached buffers.
Problem: There is no easy way to configure the behavior of the default
diagnostic "jump" mappings. For example, some users way want to show the
floating window, and some may not (likewise, some way want to only move
between warnings/errors, or disable the "wrap" parameter).
Solution: Add a "jump" table to vim.diagnostic.config() that sets
default values for vim.diagnostic.jump().
Alternatives: Users can override the default mappings to use the exact
options to vim.diagnostic.jump() that they want, but this has a couple
issues:
- While the default mappings are not complicated, they are also not
trivial, so overriding them requires users to understand
implementation details (specifically things like setting "count"
properly).
- If plugins want to change the default mappings, or configure the
behavior in any way (e.g. floating window display), it becomes even
harder for users to tweak specific behavior.
vim.diagnostic.config() already works quite well as the "entry point"
for tuning knobs with diagnostic UI elements, so this fits in nicely and
composes well with existing mental models and idioms.
Deprecate vim.diagnostic.goto_prev() and vim.diagnostic.goto_next() in
favor of a unified vim.diagnostic.jump() interface.
We cannot name the function "goto()" because some of our tooling
(luacheck and stylua) fail to parse it, presumably because "goto" is a
keyword in newer versions of Lua.
vim.diagnostic.jump() also allows moving to a specific diagnostic and
moving by multiple diagnostics at a time (useful for creating mappings
that use v:count).
For many small/simple functions (like those found in shared.lua), the
runtime of vim.validate can far exceed the runtime of the function
itself. Add an "overload" to vim.validate that uses a simple assertion
pattern, rather than parsing a full "validation spec".
Problem:
1. When interacting with multiple :InspectTree and the source buffer
windows there is a high chance of errors due to the window ids not
being updated and validated.
2. Not all InspectTree windows were closed when the source buffer was
closed.
Solution:
1. Update InspectTree window id on `CursorMoved` event and validate
source buffer window id before trying to navigate to it.
2. Close all InspectTree windows
