Re: Landing feature/more-fds for Emacs 30?

[Elliott Shugerman]

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