Problem:
The LSP client excludes paths such as Git objects and installed
dependencies from file watching. However, watchdirs() still traverses
these subtrees before filtering which directories receive watchers,
paying the filesystem and Lua traversal cost for excluded content.
Solution:
Prune excluded subdirectories during the initial walk, and document
that excluding a directory also excludes its descendants.
Using the LSP client's existing **/node_modules/*/** exclusion on a
synthetic macOS tree with 100 installed packages and 4,000 files:
Before After
Directory scans 503 103
Entries inspected 4502 202
Directory watchers 103 103
The measurements use real filesystem calls and watcher handles, with
identical watcher paths for this exclusion.
Ref: #23291
AI-assisted
Problem:
When vim._watch.watch() is used to watch a single file, libuv returns
the basename as the filename argument in the callback. The code joins
this with the watched path, producing a nonsensical path like
"/path/to/file.lua/file.lua", which causes ENOTDIR errors on
subsequent fs_stat calls.
Solution:
Check whether the watched path is a directory before joining the
filename. When watching a file, ignore the filename from libuv and
use the watched path directly.
This fixes the following warning in tests with ASAN or TSAN:
-------- Running tests from test/functional/lua/watch_spec.lua
RUN T4253 vim._watch watch() ignores nonexistent paths: 29.00 ms OK
nvim took 2006 milliseconds to exit after last test
This indicates a likely problem with the test even if it passed!
Problem:
`vim.validate()` takes two forms when it only needs one.
Solution:
- Teach the fast form all the features of the spec form.
- Deprecate the spec form.
- General optimizations for both forms.
- Add a `message` argument which can be used alongside or in place
of the `optional` argument.
Problem:
The `_watch.watch()` strategy may fail if the given path does not exist:
…/vim/_watch.lua:101: ENOENT: no such file or directory
stack traceback:
[C]: in function 'assert'
…/vim/_watch.lua:101: in function <…/vim/_watch.lua:61>
[string "<nvim>"]:5: in main chunk
- `_watch.watch()` actively asserts any error returned by `handle:start()`.
- whereas `_watch.watchdirs()` just ignores the result of `root_handle:start()`.
Servers may send "client/registerCapability" with "workspace/didChangeWatchedFiles"
item(s) (`baseUri`) which do not actually exist on the filesystem:
https://github.com/neovim/neovim/issues/28058#issuecomment-2189929424
{
method = "client/registerCapability",
params = {
registrations = { {
method = "workspace/didChangeWatchedFiles",
registerOptions = {
watchers = { {
globPattern = {
baseUri = "file:///Users/does/not/exist",
pattern = "**/*.{ts,js,mts,mjs,cjs,cts,json,svelte}"
}
},
...
}
Solution:
- Remove the assert in `_watch.watch()`.
- Show a once-only message for both cases.
- More detailed logging is blocked until we have `nvim_log` / `vim.log`.
fix#28058
inotifywait man page specifies:
The file must be specified with a relative or absolute path according to whether a relative or absolute path is given for watched directories.
So it would only work this way in case the path is relative (which at least for gopls it is not)
- Add :h fswatch-limitations that notifies user about default inotify
limitations on linux and how to adjust them
- Check for Event queue overflow message from fswatch and refer user to
new documentation
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
Problem:
vim._watch.watchdirs has terrible performance.
Solution:
- On linux use fswatch as a watcher backend if available.
- Add File watcher section to health:vim.lsp. Warn if watchfunc is
libuv-poll.
Should help with https://github.com/neovim/neovim/issues/23291
On linux `new_fs_event` doesn't support recursive watching, but we can
still use it to watch folders.
The downside of this approach is that we may end up sending some false
`Deleted` events. For example, if you save a file named `foo` there will
be a intermediate `foo~` due to the save mechanism of neovim.
The events we get from vim.uv in that case are:
- rename: foo~
- rename: foo~
- rename: foo
- rename: foo
- change: foo
- change: foo
The mechanism in this PR uses a debounce to reduce this to:
- deleted: foo~
- changed: foo
`foo~` will be the false positive.
I suspect that for the LSP case this is good enough. If not, we may need
to follow up on this and keep a table in memory that tracks available
files.
Problem: luals returns stricter diagnostics with bundled luarc.json
Solution: Improve some function and type annotations:
* use recognized uv.* types
* disable diagnostic for global `vim` in shared.lua
* docs: don't start comment lines with taglink (otherwise LuaLS will interpret it as a type)
* add type alias for lpeg pattern
* fix return annotation for `vim.secure.trust`
* rename local Range object in vim.version (shadows `Range` in vim.treesitter)
* fix some "missing fields" warnings
* add missing required fields for test functions in eval.lua
* rename lsp meta files for consistency
* docs(lua): teach lua2dox how to table
* docs(lua): teach gen_vimdoc.py about local functions
No more need to mark local functions with @private
* docs(lua): mention @nodoc and @meta in dev-lua-doc
* fixup!
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
---------
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
