Hi João,

Thanks for your interest in this issue and apologies for my slow replies.

> > I always figured the purpose of these watchers is to account for
switching git branches and the like, which is functionality I appreciate,
FWIW.
> I'm not sure I understand what you mean.  In rust-analyzer, for
> example, it watches the Cargo file (similar to a Makefile) to
> know if you're adding new libraries to it, that the language
> server must link and compile.  To know if a git branch has been
> switched, the server need to watch only one or two files under .git.

Sorry I wasn't very clear. The functionality I was alluding to is not
specific to Git, it goes for any changes to project files that are not
visited by buffers in Emacs.
Example:
- I have a single source file, "A", open in an Emacs buffer. The flycheck
icon in my modeline is green, indicating no LSP errors in the buffer (I
have lsp-mode/flycheck integration configured).
- Now, by some means outside Emacs -- a git or sed command, say -- I make a
change to source file "B", which is not visited by an Emacs buffer, in such
a way that there is now a type error in buffer "A" (maybe I've added a
method to an interface).
- Momentarily, I see the flycheck icon in my modeline turn red.

I assume it's to support this kind of magic that lsp-mode watches so many
files (all .ts files in the project, I believe).

However I just tried this with lsp-mode + rust-analyzer, and it doesn't
seem to work there -- I have restart the server for the icon to turn red .
But it does work with lsp-mode + typescript-language-server. So maybe it's
the server watching the source files after all?

Best,
Elliott




On Sun, Mar 19, 2023 at 9:17 PM João Távora <joaotavora@gmail.com> wrote:

> On Mon, Mar 20, 2023 at 1:09 AM Elliott Shugerman <eeshugerman@gmail.com>
> wrote:
> >
> > Hi João,
> >
> >
> > > What LSP server are you using?
> >
> > typescript-language-server (ts-ls)
> >
> > > Is it perhaps requesting many file watchers?
> >
> > I don't know but are you suggesting the "too many open files" in Emacs
> is related to some global OS limit? I don't _think_ that's the case as
> other apps remain stable when I run into this, it's only Emacs starts
> acting up, but I could be wrong.
>
> No, I'm not suggesting that.
>
> Servers like to watch files to known about things like build system
> changes and preferences in advance, by means of interfaces that LSP
> itself doesn't give them.  I was merely conjecturing that the server
> could be overzealous and watching files that really don't matter that
> much, like watching all the files in a directory when it really
> only needs one file to know what it wants to know.
>
> >  > Or maybe the client is overwatching on the Emacs side (what client
> are you using?).
> >
> > I'm using lsp-mode
>
> If you have the possibility, give Eglot ago.  It's in the
> Emacs 29 pretests.  Once you have it working with M-x
> eglot stably, turn off event logging (which is on be default)
> This will reduce the memory footprint dramatically and
> improve performance,
>
> > > Do you have a JSONRPC transcript that you can share with me?
> >
> > I don't know, where would I find or generate this?
>
> I wouldn't know in lsp-mode.  In Eglot it's M-x eglot-events-buffer.
>
> >
> > > Maybe, depending on the use case, it makes sense to only watch files
> on behalf of the LSP that Emacs is actually visiting.
> >
> > I always figured the purpose of these watchers is to account for
> switching git branches and the like, which is functionality I appreciate,
> FWIW.
>
> I'm not sure I understand what you mean.  In rust-analyzer, for
> example, it watches the Cargo file (similar to a Makefile) to
> know if you're adding new libraries to it, that the language
> server must link and compile.  To know if a git branch has been
> switched, the server need to watch only one or two files under .git.
>
> João
>