File watches are created over-zealously

[hpdeifel]

It seems that lsp-mode now creates file-watches for all the things in the projects root directory, which uses up resources and isn't always needed. For example, rls registers delete/change/create watchers explicitly only for Cargo.lock, Cargo.toml plus a deletion watcher for the target/ directory. Instead of creating only three file watches, lsp-mode decides to recursively watch files and directories from e.g. the target/ directory, which leads to errors like:

directory-files-recursively: Opening directory: No such file or directory, /somewhere/target/rls/debug/deps/rmeta31dHOO

Please correct me if I'm wrong, I haven't yet understood the file-watcher code in its entirety.

[yyoncho]

I agree that it is not the optimal solution, but at this point, this is the simplest solution having in mind that the language servers that are running in the folder are not defined and it is not trivial to deduplicate the paths. e. g. jdt-ls and boot-ls combined run watch 10+ file patterns and most of them are like **/*.java src/main/**. Also, they could unregister/register a file watch at any point. I agree that we might think for some optimizations, e. g. if the paths do not have wildcards - watch only them.

There is a similar issue for vscode:
microsoft/vscode#45295

directory-files-recursively: Opening directory: No such file or directory, /somewhere/target/rls/debug/deps/rmeta31dHOO

This is a bug that has to be fixed. You may ignore the target folder via lsp-file-watch-ignored for now.

[hpdeifel]

I agree that creating only the required watches is a hard problem.

This is a bug that has to be fixed. You may ignore the target folder via lsp-file-watch-ignored for now.

Does that also ignore deletion events for the folder itself? Because that would be one of the three things that rls explicitly watches.

[yyoncho]

Does that also ignore deletion events for the folder itself?

The deletion events comes from the parent folder so it is fine to ignore the folder itself. I will fix the deletion event today, so you may ignore it.

[yyoncho]

I have pushed 1f7e807 which fixes the directory-files-recursively issue and I have documented the "Limitations" in the README page. I am not planning to address the issue related to optimizing the watches since it will become irrelevant if, for example, RLS starts to monitor **.rs files.

[uqix]

From README:

In case your project contains a lot of files you might want to disable file monitoring via lsp-enable-file-watchers (you may use dir-locals).

Is dir-locals for project root or any dir in the project?

[yyoncho]

@uqix the dir local solution will be per project. But you may use lsp-file-watch-ignored to skip a particular folder from being monitored.

[axelson]

Is there a chance for this to be re-visited? Or is there any way to work around this limitation from a language server implementation side?

[yyoncho]

Is there a chance for this to be re-visited? Or is there any way to work around this limitation from a language server implementation side?

No.

I am looking at elixir-lsp/elixir-ls#448 and given the fact that you are interested in **/*.<ext> there is even no room for optimization in elisp since we should watch everything...

In general, 1000 threshold limit is very aggressive. I think that emacs will perform fine after the initial watch establishment even with 10k files to watch.