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

Previous Next

Full log

View this message in rfc822 format

From: Thomas Koch <thomas <at> koch.ro>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: João Távora <joaotavora <at> gmail.com>, 61350 <at> debbugs.gnu.org
Subject: bug#61350: Eglot over Tramp freezes with large project
Date: Tue, 7 Mar 2023 15:04:16 +0200 (EET)

Thanks Michael! What is the advantage of this patch over just removing the JUST-THIS-ONE argument? In both cases tramp is triggering accept-process-output for processes it does not own.

However with your patch there is a potential timing issue: blocking process output could still arrive between your new loop and tramps call to accept-process-output with JUST-THIS-ONE.

I'd think that there might be room for an essay "JUST-THIS-ONE considered evil"?

> Michael Albinus <michael.albinus <at> gmx.de> hat am 07.03.2023 14:49 EET geschrieben:
> 
>  
> Michael Albinus <michael.albinus <at> gmx.de> writes:
> 
> Hi Thomas & João,
> 
> before going offline just a short status update.
> 
> >> 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.
> >
> >> 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.
> 
> Thinking about, I came to a less invasive idea: Just the processes which
> possibly use the same socket for the ssh connection should accept their
> output in time. This avoids to change the behavior of other processes,
> which are not related to a given Tramp connection. And it makes me feel
> much better :-)
> 
> The small patch below, on top of Tramp 2.6.0.2, seems to fix the
> problem. I've also deactivated (in Emacs 29) João's Tramp fix, and I've
> applied the recipe given by Thomas 10 times in a row, always starting
> with "emacs -Q ...". 10 times success.
> 
> Could you please check how it works in your environment? You'll have
> some days until I'll be back. If it also works for you, I will add it to
> Tramp 2.6.0.3, and we could close this bug.
> 
> For completeness, tramp-test44-asynchronous-requests now fails in
> tramp-tests.el. But this test is already flaky (not passing successfully
> every time), so I'll investigate later what's up with this.
> 
> Best regards, Michael.

Previous Next

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