bug#61350: Eglot over Tramp freezes with large project

[João Távora]

Michael Albinus <michael.albinus@gmx.de> writes:

>>> I will do that later.  But 10 out of 10 successes in your testing is
>>> a pretty solid indication that this is on the right track.
>
> No further comments, so I guess it is OK for you?

I think the patch goes in the right direction.  The force resetting of
'timeout' to 0, which you highlighted earlier, is odd.

+  (dolist (p (delq proc (process-list)))
+    (when (tramp-file-name-equal-p
+          (process-get proc 'vector) (process-get p 'vector))
+      (setq timeout  (or timeout 0))
+      (accept-process-output p 0 nil t)))

That's because callers of 'tramp-accept-process-output' who call it with
TIMEOUT=nil will now see their expectations violated depending on
conditions they do not control.  You fully control these callers, so you
may know better, but I think this patch makes more sense, because it
keeps the contract.  

+  (dolist (p (delq proc (process-list)))
+    (when (tramp-file-name-equal-p
+          (process-get proc 'vector) (process-get p 'vector))
+      (while (accept-process-output p 0 nil t))))
   (with-current-buffer (process-buffer proc)
     (let ((inhibit-read-only t)
          last-coding-system-used

This is even more "conservative" than your patch, because it deviates
less from the current behaviour.  I've tested it (first removing the
eglot.el workaround) with my reproduction recipe to a 100% success rate
in 6-7 experiments (whereas without it it is 0%).

> I plan to install the patch next days on master, unless you oppose.

I don't, but consider my alternative.

João

PS: And I also think that Eglot over Tramp does seem to have become
faster with ControlMaster, at least in a subjective evaluation.