GNU bug report logs -
#61350
Eglot over Tramp freezes with large project
Previous Next
Full log
Message #200 received at 61350 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> 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.
This bug report was last modified 2 years and 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.