`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
