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.
