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: Sun, 05 Mar 2023 13:23:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Thomas Koch <thomas@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.





reply via email to

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