Subject: bug#61350: Eglot over Tramp freezes with large project

From: Michael Albinus <[email-masked]>
Date: Tue, 07 Mar 2023 14:52:30 +0100

João Távora <[email-masked]> writes:

Hi João,

>> 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.
>
> Yes, I also ask myself that question.  Though here, Tramp
> has "shared" ownership of them, sort of, so it's more
> conservative when compared to the current mechanics.

Indeed.

> Michael, your patch goes in the right direction but AFAIR
> a single accept-process-output is not guaranteed to bring
> into the process filter all the buffered data.
>
> In "40.9.4 Accepting Output from Processes":
>
>      [In accept-process-output, ] If PROCESS is
>      non-‘nil’ then this function does not return until some output has
>                                                  [^^^^^^^^^^^^^^^^^]
>      been received from PROCESS or PROCESS has closed the connection.
>
>
> Note "some", not "all".  So while less common, I think the hang
> can still happen.
>
> So maybe you meant:
>
>    (while (accept-process-output p 0 nil t))
>
> as suggested in that section?

That was my first idea as well. But tramp-accept-process-output itself is
called in a loop, so there's no difference in practice[1].

Pls give my patch testing, in order to see whether Tramp still blocks.

> João

Best regards, Michael.

[1]: In theory, there's no difference between theory and practice. In
practice, there is. :-)