bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61350: Eglot over Tramp freezes with large project


From: Michael Albinus
Subject: bug#61350: Eglot over Tramp freezes with large project
Date: Fri, 24 Feb 2023 18:19:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

João Távora <joaotavora@gmail.com> writes:

Hi,

sorry for the delay, I have been out of order the last days :-(

>> Thanks João, but with the jsonrpc patch it is the same as with the previous 
>> patch: Emacs still hangs. This time I could unfreeze it with C-g, but it 
>> hangs again a moment later.

I confirm, that with the jsonrpc patch the problem still happens to
me. I'm using the emacs-29 branch for test.

> I'll need you to describe the conditions that lead Emacs to hang.
> An Emacs -Q run, a server, an example file, all in all, a MRE. See
> how this user informally but very effectively reported a bug in Eglot:
>
>    https://lists.gnu.org/archive/html/emacs-devel/2023-02/msg00851.html
>
> Here, I don't even understand whether you're trying this with TRAMP
> or locally.

I have prepared the test as described by Thomas in
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61350#5>. After setting
up everything on the remote side, I have called

--8<---------------cut here---------------start------------->8---
# ~/src/emacs-29/src/emacs -Q 
/ssh:ubuntu-2204:/home/albinus/src/yacy_search_server/source/net/yacy/yacy.java 
-f eglot
--8<---------------cut here---------------end--------------->8---

The remote machine is a virgin Ubuntu VM.

> If I can't see the error you're facing in my machine, it's likely
> I won't be of any help.  I can report I've been working for a few
> hours with that patch with the Clangd server with no problems using
> a local project (no TRAMP).
>
> We can also wait for Michael to try out the patch, as I'm sure he
> can report any problems just as clearly as he last did in this
> thread.

As said above, same result: eglot hangs. Your patch doesn't change the
game. You don't call jsonrpc--notification-dispatcher anymore in the
process filter directly. But calling it by a timer has the same effect:
The process filter (accepting output) is still active, and the called
function in the timer still uses file-truename, which tries to read
output from the Tramp process.

Again, I still believe we need a general solution in Tramp, using threads.

> João

Best regards, Michael.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]