GNU bug report logs - #61350
Eglot over Tramp freezes with large project

Previous Next

Full log

Message #161 received at 61350 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Thomas Koch <thomas <at> koch.ro>
Cc: João Távora <joaotavora <at> gmail.com>,
 61350 <at> debbugs.gnu.org
Subject: Re: bug#61350: Eglot over Tramp freezes with large project
Date: Sun, 05 Mar 2023 13:23:59 +0100

Thomas Koch <thomas <at> koch.ro> writes:

Hi Thomas,

> Thanks Michael for digging! This is exactly what I also think happens.
>
> However my conclusion is different. I consider the root-cause to be the use of JUST-THIS-ONE in tramps call to accept-process-output. Please check my comment to bug
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12145

I've seen this. And yes, we shall fix the problems described there.

> Applying a workaround (adding extra code to surpress ControlMaster
> with a newly introduced hook) would increase the complexity and thus
> brittleness. I believe the right thing to do is remove JUST-THIS-ONE
> in Tramp and fix find-name-dired and any other place that's broken.

I won't change Tramp this way in Emacs 29. It is in feature freeze,
closed to pretest. I cannot risk to destabilize it.

And as we see with the find-name-dired case, there might be collateral
damages if we change Tramp this way.

And I don't believe, that adding a hook in Eglot is worse than what we
have now, where Eglot manipulates Tramp data. Whenever we need to change
Tramp in this area, it wouldn't apply in Egloot. A hook is much better
suited, and we use the very same technique already with compile.el.

> As a practical roadmap you could add an option to Tramp to disable
> JUST-THIS-ONE and recommend its use. Later the options default could
> be toggled. Eventually the option can go away.

Might be applicable in the master branch. But first we need much more
checks that it doesn't break something else.

I'm always uncomfortable to change Tramp such a way that other packages
could be broken. Letting Tramp accept process output for all existing
processes doesn't seem to be the right thing to me, although I admit
that it seems to fix the specific problem we're discussing here.

> Eglot could emit a warning if it sees the above tramp option not being
> used. (... could lead to Emacs hanging. Are you sure to continue
> (y/n)?)

No check in Eglot. A hint in the manual would be sufficient I believe.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.