--- Begin Message ---
|
Subject: |
30.0.50; [EGLOT] Emacs freezes when server sends a ton of progress notifications |
|
Date: |
Sat, 21 Oct 2023 12:10:49 -0700 |
X-Debbugs-CC: joaotavora@gmail.com
I use rust’s language server (rust-analyzer) with eglot. And whenever I turn
eglot on for a project, Emacs freezes for a good 30 seconds, busy updating the
eglot progress indicator, before I can do anything. I think the reason is that
the rust language server sends a ton of progress notifications, which
completely blocks Emacs before it’s done.
Setting eglot-report-progress to nil doesn’t help me, presumably because eglot
still needs to process the notifications.
I wonder if we can only take a sample of the progress notifications, and ignore
the majority, so that Emacs is free to respond to user input?
In the same vain, I wonder if we can instruct Emacs to filter out some messages
from the server at process filter level and never call into lisp for these
messages, such that some particularly noisy servers (eg,
typescript-language-server) won’t slow down Emacs a perceivable amount?
I attached the events log during the start up of eglot in my rust project. As
you can see, it sends a dozen notifications per second.
Yuan
indexing-events.log
Description: Binary data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#66669: 30.0.50; [EGLOT] Emacs freezes when server sends a ton of progress notifications |
|
Date: |
Sun, 22 Oct 2023 17:39:42 -0700 |
> On Oct 22, 2023, at 7:52 AM, João Távora <joaotavora@gmail.com> wrote:
>
> On Sun, Oct 22, 2023 at 5:50 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> Cc: joaotavora@gmail.com
>>> From: Yuan Fu <casouri@gmail.com>
>>> Date: Sat, 21 Oct 2023 12:10:49 -0700
>>>
>>> I use rust’s language server (rust-analyzer) with eglot. And whenever I
>>> turn eglot on for a project, Emacs freezes for a good 30 seconds, busy
>>> updating the eglot progress indicator, before I can do anything. I think
>>> the reason is that the rust language server sends a ton of progress
>>> notifications, which completely blocks Emacs before it’s done.
>>>
>>> Setting eglot-report-progress to nil doesn’t help me, presumably because
>>> eglot still needs to process the notifications.
>>
>> Can't this information be processed in chunks, not in one go?
>
> Maybe, depending on what that means. I think it's important to
> get to the bottom of Yuan's "presumably" first, preferably by
> reproducing his problem.
Apologize for doubting eglot's ability to process messages :-) When trying to
reproduce the problem, I eventually found out that it was project-files that
was blocking. And project-files was blocking because I used a custom project
method, which doesn’t properly ignore the build directory, which contains a ton
of small files.
> * Have you profiled? Have you tried setting eglot-events-buffer-size
> to 0 (and restart Eglot) as suggested in the Eglot manual? Many
> performance problems are due to JSON objects being pretty printed in
> the Eglot events buffer (BTW some users ask me to turn it to 0 by
> default, but the pros don't outweigh the cons, which in this case is
> we would lose a valuable tool for newbie users with exotic servers to
> send me their debug data easily)
I do have eglot-events-buffer-size set to 0. I observed the freeze, reset it to
some large value, and saw a bunch of notifications, so I assumed that was the
problem. That turns out to be very wrong :-)
Personally I also think the default value should be 0. (I wonder if disabling
pp would improve it enough?) Eglot is really borderline non-usable when the
value is non-0 and the language server is chatty (eg, rust, typescript). I
certainly don’t want people to try out eglot, see the lag, and conclude that
“Emacs is slow”.
Maybe providing a simple command like M-x eglot-enable-logging, and tell new
users to turn this on and restart eglot, is good enough. But I’m not the one
that dealt with eglot bug reports, maybe restarting eglot can’t reproduce the
error in many cases?
Yuan
--- End Message ---