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
Problem: there is missing default title highlight when highlight not defined in title text chunk.
Solution: when attr is not set use default title highlight group.
This is mostly an aesthetic change, although there are a few new pieces
of information included. Originally I wanted to investigate including
server capabilities in the healthcheck, but until we have the ability to
fold/unfold text in health checks that would be too much information.
Problem: Can't use a blockwise selection with a width for getregion().
Solution: Add support for blockwise selection with width like the return
value of getregtype() or the "regtype" value of TextYankPost
(zeertzjq).
closes: vim/vim#14842afc2295c22
The new default SwapExists autocommand displays warning text (W325) but
does not use the WarningMsg highlight group as other warnings do. Use
the WARN log level when displaying this warning.
Problem: `CompleteDone` currently does not specify the reason for why completion was done, which is problematic for completion plugins as they cannot know whether the event was triggered due to the completion being canceled, accepted, or for some other reason.
Solution: Add a `reason` key to `v:event`, which is set by `CompleteDone` to indicate why completion ended.
Deprecation with vim.deprecate is currently too noisy. Show the
following warning instead:
[function] is deprecated. Run ":checkhealth vim.deprecated" for more information.
The important part is that the full message needs to be short enough to
fit in one line in order to not trigger the "Press ENTER or type command
to continue" prompt.
The full information and stack trace for the deprecated functions will
be shown in the new healthcheck `vim.deprecated`.
In other words, `gx` works regardless of where it was used in
`[...](https://...)`. This only works on markdown buffers.
Co-authored-by: ribru17 <ribru17@gmail.com>
Problem: getregionpos() can't properly indicate positions beyond eol.
Solution: Add an "eol" flag that enables handling positions beyond end
of line like getpos() does (zeertzjq).
Also fix the problem that a position still has the coladd beyond the end
of the line when its column has been clamped. In the last test case
with TABs at the end of the line the old behavior is obviously wrong.
I decided to gate this behind a flag because returning positions that
don't correspond to actual characters in the line may lead to mistakes
for callers that want to calculate the length of the selected text, so
the behavior is only enabled if the caller wants it.
closes: vim/vim#148382b09de9104
Problem: Currently comment detection, addition, and removal are done
by matching 'commentstring' exactly. This has the downside when users
want to add comment markers with space (like with `-- %s`
commentstring) but also be able to uncomment lines that do not contain
space (like `--aaa`).
Solution: Use the following approach:
- Line is commented if it matches 'commentstring' with trimmed parts.
- Adding comment is 100% relying on 'commentstring' parts (as is now).
- Removing comment is first trying exact 'commentstring' parts with
fallback on trying its trimmed parts.
Problem: getregionpos() doesn't handle one char selection.
Solution: Handle startspaces differently when is_oneChar is set.
Also add a test for an exclusive charwise selection with
multibyte chars (zeertzjq)
closes: vim/vim#1482552a6f34887
This will help manage the overly granular checkhealth completion to go
from
```
vim.health
vim.lsp
vim.provider.clipboard
vim.provider.node
vim.provider.perl
vim.provider.python
vim.provider.ruby
vim.treesitter
```
to
```
vim.health
vim.lsp
vim.provider
vim.treesitter
```
`vim.health` is not a "plugin" but part of our Lua API and the
documentation should reflect that. This also helps make the
documentation maintenance easier as it is now generated.
Problem: The changetracking state can de-sync when reloading a buffer
with more than one LSP client attached.
Solution: Fully detach all clients from the buffer to force buf_state to
be re-created.
Problem: layout i.e. whitespace that is part of codelenses is currently
displayed as weird symbols and large amounts of spaces
Solution: replace all consecutive whitespace symbols with a single space
character when trying to display codelenses as virtual text
Problem: getregionpos() wrong with blockwise mode and multibyte.
Solution: Use textcol and textlen instead of start_vcol and end_vcol.
Handle coladd properly (zeertzjq).
Also remove unnecessary buflist_findnr() in add_regionpos_range(), as
getregionpos() has already switched buffer.
closes: vim/vim#14805c95e64f41f
Problem: Cannot get a list of positions describing a region
(Justin M. Keyes, after v9.1.0120)
Solution: Add the getregionpos() function
(Shougo Matsushita)
fixes: vim/vim#14609closes: vim/vim#14617b4757e627e
Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: On nvim 11.0-dev, deprecation warnings due to an use of
hard-deprecated APIs such as:
- `vim.diagnostic.disable()`
- `vim.diagnostic.is_disabled()`
etc. are not accompanied by backtrace information. It makes difficult
for users to figure out which lines or which plugins are still using
deprecated APIs.
Solution: use `backtrace = true` in vim.deprecate() call.
The namespacing for healthchecks for neovim modules is inconsistent and
confusing. The completion for `:checkhealth` with `--clean` gives
```
nvim
provider.clipboard
provider.node
provider.perl
provider.python
provider.ruby
vim.lsp
vim.treesitter
```
There are now three top-level module names for nvim: `nvim`, `provider`
and `vim` with no signs of stopping. The `nvim` name is especially
confusing as it does not contain all neovim checkhealths, which makes it
almost a decoy healthcheck.
The confusion only worsens if you add plugins to the mix:
```
lazy
mason
nvim
nvim-treesitter
provider.clipboard
provider.node
provider.perl
provider.python
provider.ruby
telescope
vim.lsp
vim.treesitter
```
Another problem with the current approach is that it's not easy to run
nvim-only healthchecks since they don't share the same namespace. The
current approach would be to run `:che nvim vim.* provider.*` and would
also require the user to know these are the neovim modules.
Instead, use this alternative structure:
```
vim.health
vim.lsp
vim.provider.clipboard
vim.provider.node
vim.provider.perl
vim.provider.python
vim.provider.ruby
vim.treesitter
```
and
```
lazy
mason
nvim-treesitter
telescope
vim.health
vim.lsp
vim.provider.clipboard
vim.provider.node
vim.provider.perl
vim.provider.python
vim.provider.ruby
vim.treesitter
```
Now, the entries are properly sorted and running nvim-only healthchecks
requires running only `:che vim.*`.
The optimizations that vim.iter uses for array-like tables don't require
that the source table has no holes. The only thing that needs to change
is the determination if a table is "list-like": rather than requiring
consecutive, integer keys, we can simply test for (positive) integer
keys only, and remove any holes in the original array when we make a
copy for the iterator.
Problem: `has-ancestor?` is O(n²) for the depth of the tree since it iterates over each of the node's ancestors (bottom-up), and each ancestor takes O(n) time.
This happens because tree-sitter's nodes don't store their parent nodes, and the tree is searched (top-down) each time a new parent is requested.
Solution: Make use of new `ts_node_child_containing_descendant()` in tree-sitter v0.22.6 (which is now the minimum required version) to rewrite the `has-ancestor?` predicate in C to become O(n).
For a sample file, decreases the time taken by `has-ancestor?` from 360ms to 6ms.
Problem:
vim.fs.normalize() normalizes too much vim.loader and is slow.
Solution:
Make it faster by doing less. This reduces the times spent in
vim.fs.normalize in vim.loader from ~13ms -> 1-2ms.
Numbers from a relative benchmark:
- Skipping `vim.validate()`: 285ms -> 230ms
- Skipping `path_resolve_dot()`: 285ms -> 60ms
- Skipping `double_slash`: 60ms -> 35ms
Closes https://github.com/neovim/neovim/issues/28484.
Closes https://github.com/neovim/neovim/issues/28719.
Co-authored-by: Chris <crwebb85@gmail.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Jake B <16889000+jakethedev@users.noreply.github.com>
Co-authored-by: Jonathan Raines <jonathan.s.raines@gmail.com>
Co-authored-by: Yi Ming <ofseed@foxmail.com>
Co-authored-by: Zane Dufour <zane@znd4.me>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Re-normalizing a path after a `joinpath` isn't necessary. Calling
`normalize` on each child directory had quite a bit of impact when
traversing a large directory.
A simple test showed:
Before: ~144ms
After: ~80ms
running the following logic against a dir with 4367 child folders and
25826 files:
local files = {}
local start = uv.hrtime()
for name, type in vim.fs.dir(path, { depth = max_depth }) do
table.insert(files, { name, type })
end
local duration = uv.hrtime() - start
Relates to https://github.com/neovim/neovim/issues/23291
Problem: The column width 10 for parser name (lang) is too short.
For example, `markdown_inline` has 15 characters, which results in a
slight misalignment with other lines.
e.g. it looked like:
```
- OK Parser: markdown ABI: 14, path: .../parser/markdown.so
- OK Parser: markdown_inline ABI: 14, path: .../parser/markdown_inline.so
- OK Parser: php ABI: 14, path: .../parser/php.so
```
Solution: Use column width 20. As of now, the longest name among those
available in nvim-treesitter has length 18 (`haskell_persistent`).
e.g.:
```
- OK Parser: markdown ABI: 14, path: .../parser/markdown.so
- OK Parser: markdown_inline ABI: 14, path: .../parser/markdown_inline.so
- OK Parser: php ABI: 14, path: .../parser/php.so
```
Problem:
The nvim_win_xx_ns function family introduced in ba0370b1d7
needs more bake-time. Currently it's narrowly defined for windows, but
other scopes ("buffer") and features are likely in the future.
Solution:
- Rename the API with double-underscore to mark it as EXPERIMENTAL.
TODO/FUTURE:
- Rename and change the signature to support more than just "window"
scope, and for other flexibility.
- Open question: we could choose either:
- "store scopes on namespaces", or
- "store namespaces on scopes (w:/b:/…)"
Problem: filetype: zsh module files are not recognized
Solution: Detect '*.mdh' and '*.epro' as C filetype, '*.mdd' as zsh
filetype, determine zsh-modules '*.pro' from from it's content
(Wu, Zhenyu)
closes: vim/vim#14737887a38cee7
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem:
The file watcher backends for Linux have too many limitations and
doesn't work reliably.
Solution:
disable didChangeWatchedFiles on Linux
Ref: #27807, #28058, #23291, #26520
Rename the field `result` to `params` in the `data` table for
`LspProgress` autocmds. This aligns with LspNotify.
The previous name was chosen because the initial handler implementation
mistakenly had a parameter name `result` instead of `params` for the
`$/progress` LSP "notification" handler. However, `params` would be a
more appropriate name that is more consistent with the underlying LSP
type (`ProgressParams`).
See also: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#progress
Problem:
inlay_hint `enable(<no args>)` does not activate inlay hints on open
buffers. If a buffer does not have a corresponding `bufstate` in
`bufstates`, then `enable` all buffers will not take effect on it.
Solution:
Make the effective range determined by the loaded buffers.
Fix#28624
Revert the default LSP mappings before the 0.10 release as these might
need some further consideration. In particular, it's not clear if "c"
prefixed maps in Normal mode are acceptable as defaults since they
interfere with text objects or operator ranges.
We will re-introduce default mappings at the beginning of the 0.11
release cycle, this reversion is only for the imminent 0.10 release.
Some parsers for, e.g., LaTeX or PHP have anonymous nodes like `"\"` or `"\text"` that behave wonkily (especially the first example) in the `InspectTree` window, so this PR escapes them by adding another backslash in front of them
reverts e0d92b9cc2#28502
Problem:
`vim.ui.open()` has a `pcall()` like signature, under the assumption
that this is the Lua idiom for returning result-or-error. However, the
`result|nil, errmsg|nil` pattern:
- has precedent in:
- `io.open`
- `vim.uv` (`:help luv-error-handling`)
- has these advantages:
- Can be used with `assert()`:
```
local result, err = assert(foobar())
```
- Allows LuaLS to infer the type of `result`:
```
local result, err = foobar()
if err then
...
elseif result then
...
end
```
Solution:
- Revert to the `result|nil, errmsg|nil` pattern.
- Document the pattern in our guidelines.
This avoids redraw when adding/removing an empty namespace for a window.
This also avoids marktree traversal when clearing a namespace that has
already been cleared, which is added as a benchmark.
Experimental and subject to future changes.
Add a way to redraw certain elements that are not redrawn while Nvim is waiting
for input, or currently have no API to do so. This API covers all that can be
done with the :redraw* commands, in addition to the following new features:
- Immediately move the cursor to a (non-current) window.
- Target a specific window or buffer to mark for redraw.
- Mark a buffer range for redraw (replaces nvim__buf_redraw_range()).
- Redraw the 'statuscolumn'.
Problem:
Inlay hints `enable()` does not fully implement the `:help dev-lua` guidelines:
Interface conventions ~
- When accepting a buffer id, etc., 0 means "current buffer", nil means "all
buffers". Likewise for window id, tabpage id, etc.
- Examples: |vim.lsp.codelens.clear()| |vim.diagnostic.enable()|
Solution:
Implement globally enabling inlay hints.
* refactor(lsp): do not rely on `enable` to create autocmds
* refactor(lsp): make `bufstates` a defaulttable
* refactor(lsp): make `bufstate` inherit values from `globalstate`
* feat(lsp): `vim.lsp.inlay_hints` now take effect on all buffers by default
* test(lsp): add basic tests for enable inlay hints for all buffers
* test(lsp): add test cases cover more than one buffer
Problem: filetype: stylus files not recognized
Solution: Detect '*.styl' and '*.stylus' as stylus filetype,
include indent, filetype and syntax plugin
(Philip H)
closes: vim/vim#146562d919d2744
Co-authored-by: Philip H <47042125+pheiduck@users.noreply.github.com>
This reverts commit 15e77a56b7.
Subpriorities were added in https://github.com/neovim/neovim/pull/27131
as a mechanism for enforcing query order when using iter_matches in the
Tree-sitter highlighter. However, iter_matches proved to have too many
complications to use in the highlighter so we eventually reverted back
to using iter_captures (https://github.com/neovim/neovim/pull/27901).
Thus, subpriorities are no longer needed and can be removed.
Problem: filetype: .out files recognized as tex files
Solution: Do not set an explicit filetype until it is clear what this
should be (shane.xb.qian)
closes: vim/vim#14670e35478bc9d
Co-authored-by: shane.xb.qian <shane.qian@foxmail.com>
Problem: Kbuild files are not recognized.
Solution: Detect Kbuild files as make files.
(Bruno Belanyi)
closes: vim/vim#146765cbc9a69e5
Co-authored-by: Bruno BELANYI <bruno@belanyi.fr>
Follow-up to #28490
Problem:
The new behaviour of goto_next/prev() of navigating to the next highest
severity doesn't work well when diagnostic providers have different
interpretations of severities. E.g. the user may be blocked from
navigating to a useful LSP warning, due to some linter error.
Solution:
The behaviour of next highest severity is now a hidden option
`_highest = true`. We can revisit how to integrate this behaviour
during the 0.11 cycle.
Problem:
The new LSP "refactor menu" keybinding "crr" is also defined in visual
mode, which overlaps with the builtin "c".
Solution:
Use CTRL-R instead of "crr" for visual mode.
fix#28528
Based on feedback from #28324, pass -H and -I to regular grep
(available on all platforms officially supported by Neovim), and
only pass -uu to ripgrep. This makes :grep ignore binary files by
default in both cases.
* fix(treesitter): enforce lowercase language names
Problem: On case-insensitive file systems (e.g., macOS), `has_parser`
will return `true` for uppercase aliases, which will then try to inject
the uppercase language unsuccessfully.
Solution: Enforce and assume parser names to be lowercase when
resolving language names.
Reverts parts of https://github.com/neovim/neovim/pull/27674
LSP snippets typically do include tabs or spaces to add extra
indentation and don't rely on the client using `autoindent`
functionality.
For example:
public static void main(String[] args) {\n\t${0}\n}
Notice the `\t` after `{\n`
Adding spaces or tabs independent of that breaks snippets for languages
like Haskell where you can have snippets like:
${1:name} :: ${2}\n${1:name} ${3}= ${0:undefined}
To generate:
name ::
name = undefined
Problem: when line is blank link then there will got an invalid column number in math.min compare.
Solution: make sure the min column number is 0 not an illegal number.
Problem:
vim.iter has both `rfind()` and various `*back()` methods, which work
in "reverse" or "backwards" order. It's inconsistent to have both kinds
of names, and "back" is fairly uncommon (rust) compared to python
(rfind, rstrip, rsplit, …).
Solution:
- Remove `nthback()` and let `nth()` take a negative index.
- Because `rnth()` looks pretty obscure, and because it's intuitive
for a function named `nth()` to take negative indexes.
- Rename `xxback()` methods to `rxx()`.
- This informally groups the "list-iterator" functions under a common
`r` prefix, which helps discoverability.
- Rename `peekback()` to `pop()`, in duality with the existing `peek`.
Fixes regression introduced in #28030
If an LSP server is restarted, then the associated `nvim_buf_attach`
call will not detach if no buffer changes are sent between the client
stopping and a new one being created. This leads to `nvim_buf_attach`
being called multiple times for the same buffer, which then leads to
changetracking sending duplicate requests to the server (one per
attach).
To solve this, introduce separate tracking (client agnostic) on which
buffers have had calls to `nvim_buf_attach`.
vim.notify cannot be suppressed and it is not always necessary to
display a visible warning to the user if the RPC process fails to start.
For instance, a user may have the same LSP configuration across systems,
some of which may not have all of the LSP server executables installed.
In that case, the user receives a notification every time a file is
opened that they cannot suppress.
Instead of using vim.notify in vim.lsp.rpc, propagate a normal error up
through the call stack and use vim.notify in vim.lsp.start() only if
the "silent" option is not set.
This also updates lsp.start_client() to return an error message as its
second return value if an error occurred, rather than calling vim.notify
directly. Callers of lsp.start_client() will need to update call sites
appropriately if they wish to report errors to the user (or even better,
switch to vim.lsp.start).
Problem:
`vim.ui.open` unnecessarily invents a different success/failure
convention. Its return type was changed in 57adf8c6e0, so we might as
well change it to have a more conventional form.
Solution:
Change the signature to use the `pcall` convention of `status, result`.
vim.fs.root() is a function for finding a project root relative to a
buffer using one or more "root markers". This is useful for LSP and
could be useful for other "projects" designs, as well as for any plugins
which work with a "projects" concept.
Instead of adding all diagnostics matching lnum filters to a table, and
then copying that table to another table while applying the severity
filter, this changes the flow to only add diagnostics matching both
filters in the first pass.
Problem: `vim.deprecate()` can be relatively significantly slower than
the deprecated function in "Nvim" plugin.
Solution: Optimize checks for "Nvim" plugin. This also results into not
distinguishing "xxx-dev" and "xxx" versions when doing checks, which
is essentially covered by the deprecation logic itself.
With this rewrite I get the times from #28459: `{ 0.024827, 0.003797, 0.002024, 0.001774, 0.001703 }`.
For quicker reference:
- On current Nightly it is something like `{ 3.72243, 0.918169, 0.968143, 0.763256, 0.783424 }`.
- On 0.9.5: `{ 0.002955, 0.000361, 0.000281, 0.000251, 0.00019 }`.
ref https://github.com/neovim/neovim/issues/19596
FAILED test/functional/plugin/health_spec.lua @ 37: :checkhealth completions can be listed via getcompletion()
test/functional/plugin/health_spec.lua:40: Expected objects to be the same.
Passed in:
(string) 'provider.node'
Expected:
(string) 'provider.clipboard'
stack traceback:
test/functional/plugin/health_spec.lua:40: in function <test/functional/plugin/health_spec.lua:37>
Problem:
Besides being redundant with vim.iter():flatten(), `tbl_flatten` has
these problems:
- Has `tbl_` prefix but only accepts lists.
- Discards some results! Compare the following:
- iter.flatten():
```
vim.iter({1, { { a = 2 } }, { 3 } }):flatten():totable()
```
- tbl_flatten:
```
vim.tbl_flatten({1, { { a = 2 } }, { 3 } })
```
Solution:
Deprecate tbl_flatten.
Note:
iter:flatten() currently fails ("flatten() requires a list-like table")
on this code from gen_lsp.lua:
local anonym = vim.iter({ -- remove nil
anonymous_num > 1 and '' or nil,
'---@class ' .. anonymous_classname,
}):flatten():totable()
Should we enhance :flatten() to work for arrays?
Problem:
While the fold level computation is incremental, the evaluation of the
foldexpr is done on the full buffer. Despite that the foldexpr reads
from the cache, it can take tens of milliseconds for moderately big (10K
lines) buffers.
Solution:
Track the range of lines on which the foldexpr should be evaluated.
Problem:
The use-case for the convenience functions vim.iter.map(),
vim.iter.filter(), vim.iter.totable() is not clear.
Solution:
Drop them for now. We can revisit after 0.10 release.
Problem: runtime(uci): No support for uci file types
(Wu, Zhenyu)
Solution: include basic uci ftplugin and syntax plugins
(Colin Caine)
closes: vim/vim#145754b3fab14db
Co-authored-by: Colin Caine <complaints@cmcaine.co.uk>
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem:
We need to establish a pattern for `enable()`.
Solution:
- First `enable()` parameter is always `enable:boolean`.
- Update `vim.diagnostic.enable()`
- Update `vim.lsp.inlay_hint.enable()`.
- It was not released yet, so no deprecation is needed. But to help
HEAD users, it will show an informative error.
- vim.deprecate():
- Improve message when the "removal version" is a *current or older* version.
Problem:
The order of the validation performed by vim.validate() is
unpredictable.
- harder to write reliable tests.
- confusing UX because validation result might return different errors randomly.
Solution:
Iterate the input using `vim.spairs()`.
Future:
Ideally, the caller could provide an "ordered dict".
Problem: filetype: some requirements files are not recognized
Solution: Detect '*-requirements.txt', 'constraints.txt',
'requirements.in', 'requirements/*.txt' and 'requires/*.txt'
as requirements filetype, include pip compiler, include
requirements filetype and syntax plugin
(Wu, Zhenyu, @raimon49)
closes: vim/vim#14379f9f5424d3e
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Co-authored-by: raimon <raimon49@hotmail.com>
Problem: filetype: some mail tools not recognized
Solution: Detect '.mbsncrc' as conf, '.msmtprc' as msmtp
and '.notmuch-config' as ini filetype
(Shane-XB-Qian)
closes: vim/vim#14533a7a9a476cf
Co-authored-by: shane.xb.qian <shane.qian@foxmail.com>
Problem:
vim.diagnostic.enable() does not match the signature of vim.lsp.inlay_hint.enable()
Solution:
- Change the signature so that the first 2 args are (bufnr, enable).
- Introduce a 3rd `opts` arg.
- Currently it only supports `opts.ns_id`.
Problem:
`vim.diagnostic.is_disabled` and `vim.diagnostic.disable` are unnecessary
and inconsistent with the "toggle" pattern (established starting with
`vim.lsp.inlay_hint`, see https://github.com/neovim/neovim/pull/25512#pullrequestreview-1676750276
As a reminder, the rationale is:
- we always need `enable()`
- we always end up needing `is_enabled()`
- "toggle" can be achieved via `enable(not is_enabled())`
- therefore,
- `toggle()` and `disable()` are redundant
- `is_disabled()` is a needless inconsistency
Solution:
- Introduce `vim.diagnostic.is_enabled`, and `vim.diagnostic.enable(…, enable:boolean)`
- Note: Future improvement would be to add an `enable()` overload `enable(enable:boolean, opts: table)`.
- Deprecate `vim.diagnostic.is_disabled`, `vim.diagnostic.disable`
Problem:
vim.ui.open "locks up" Nvim if the spawned process does not terminate. #27986
Solution:
- Change `vim.ui.open()`:
- Do not call `wait()`.
- Return a `SystemObj`. The caller can decide if it wants to `wait()`.
- Change `gx` to `wait()` only a short time.
- Allows `gx` to show a message if the command fails, without the
risk of waiting forever.
Problem: String interpolation fails for Dict type
Solution: Support Dict data type properly, also support :put =Dict
(without having to convert it to string() first)
(Yegappan Lakshmanan)
fixes: vim/vim#14529closes: vim/vim#14541f01493c550
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: noautocmd is confusing; despite its name, it doesn't block all
autocommands (instead it blocks only those related to setting the buffer), and
is commonly used by plugins to open windows while producing minimal
side-effects.
Solution: be consistent and block all autocommands when noautocmd is set.
This includes WinNew (again), plus autocommands from entering the window (if
enter is set) like WinEnter, WinLeave, TabEnter, .etc.
See the discussion at https://github.com/neovim/neovim/pull/14659#issuecomment-2040029517
for more information.
Remove win_set_buf's noautocmd argument, as it's no longer needed.
NOTE: pum_create_float_preview sets noautocmd for win_set_buf, but all its
callers already use block_autocmds.
Despite that, pum_create_float_preview doesn't actually properly handle
autocommands (it has no checks for whether those from win_enter or
nvim_create_buf free the window).
For now, ensure autocommands are blocked within it for correctness (in case it's
ever called outside of a block_autocmds context; the function seems to have been
refactored in #26739 anyway).
Problem:
The `:terminal` auto-close logic does not support `&shell` that has
arguments, e.g., `/bin/bash -O globstar`.
Solution:
Join `argv` and match `&shell`. This is not perfect since `&shell` may
contain irregular spaces and quotes, but it seems to be good enough.
This reverts commit 4382d2ed56.
The story for this feature was left in an incomplete state. It was never
the intention to unilaterally fold all information, only the ones that
did not contain relevant information. This feature does more harm than
good in its incomplete state.
Problem: filetype: some history files are not recognized
Solution: Add some history patterns to filetype.vim
(Wu, Zhenyu)
closes: vim/vim#14513da70feabea
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: xilinx files are not recognized
Solution: Add a few xilinx specific file patterns,
inspect lpr files for being xml/pascal
(Wu, Zhenyu)
closes: vim/vim#14454614691ceef
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: some TeX files are not recognized
Solution: Add more patterns for TeX files and inspect
a few more files for being TeX files
(Wu, Zhenyu)
closes: vim/vim#1445661ee833a50
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
To avoid repeatedly requesting a buffer multiple times before a request is completed, the current implementation puts the requested buffer into the active_refreshes table before requesting.
But since we only remove the buffer from active_refreshes in the lsp-handler of textDocument/codeLens, this will cause if the user sends a request that cannot trigger lsp-handler (for example, if there is an LSP server attached to the current buffer, and especially when the user creates an autocmd which performs vim.lsp.codelens.refresh after the BufEnter event is triggered like in the document example), this buffer will be put into active_refreshes, and there is no way to remove it, which will result in all subsequent vim.lsp.codelens.refresh not requesting textDocument/codeLens.
According to the LSP specification, the CodeLens.command is optional but the CodeLens.command.command is not optional, which means the correct representation of a display-only code lens is indeed one with a command with a title to display and an empty string as command.
Problem: filetype: R history files are not recognized
Solution: Detect '.Rhistory' files as r filetype
(Wu, Zhenyu)
closes: vim/vim#14440fc21b6437c
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
runtime(doc): Normalise builtin-function optional parameter formatting
These should generally be formatted as func([{arg}]) and referenced as
{arg} in the description.
closes: vim/vim#144389cd9e759ab
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Design
- Enable commenting support only through `gc` mappings for simplicity.
No ability to configure, no Lua module, no user commands. Yet.
- Overall implementation is a simplified version of 'mini.comment'
module of 'echasnovski/mini.nvim' adapted to be a better suit for
core. It basically means reducing code paths which use only specific
fixed set of plugin config.
All used options are default except `pad_comment_parts = false`. This
means that 'commentstring' option is used as is without forcing single
space inner padding.
As 'tpope/vim-commentary' was considered for inclusion earlier, here is
a quick summary of how this commit differs from it:
- **User-facing features**. Both implement similar user-facing mappings.
This commit does not include `gcu` which is essentially a `gcgc`.
There are no commands, events, or configuration in this commit.
- **Size**. Both have reasonably comparable number of lines of code,
while this commit has more comments in tricky areas.
- **Maintainability**. This commit has (purely subjectively) better
readability, tests, and Lua types.
- **Configurability**. This commit has no user configuration, while
'vim-commentary' has some (partially as a counter-measure to possibly
modifying 'commentstring' option).
- **Extra features**:
- This commit supports tree-sitter by computing `'commentstring'`
option under cursor, which can matter in presence of tree-sitter
injected languages.
- This commit comments blank lines while 'tpope/vim-commentary' does
not. At the same time, blank lines are not taken into account when
deciding the toggle action.
- This commit has much better speed on larger chunks of lines (like
above 1000). This is thanks to using `nvim_buf_set_lines()` to set
all new lines at once, and not with `vim.fn.setline()`.
Problem:
Some servers don't report progress during initialize unless the client
sets the `workDoneToken`
See https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initiatingWorkDoneProgress
In particular:
> There is no specific client capability signaling whether a client will
> send a progress token per request. The reason for this is that this is
> in many clients not a static aspect and might even change for every
> request instance for the same request type. So the capability is signal
> on every request instance by the presence of a workDoneToken property.
And:
> Servers can also initiate progress reporting using the
> window/workDoneProgress/create request. This is useful if the server
> needs to report progress outside of a request (for example the server
> needs to re-index a database). The token can then be used to report
> progress using the same notifications used as for client initiated
> progress.
So far progress report functionality was relying entirely on the latter.
Solution:
Set a `workDoneToken`
Closes https://github.com/neovim/neovim/issues/27938
