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

Previous Next

Full log

Message #254 received at 61350 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: Thomas Koch <thomas <at> koch.ro>, Michael Albinus <michael.albinus <at> gmx.de>,
 61350 <at> debbugs.gnu.org
Subject: Re: bug#61350: Eglot over Tramp freezes with large project
Date: Wed, 15 Mar 2023 17:43:22 -0400

>> I think we understand some of the problems well enough to think
>> about solutions.
> Does that "some" include _this_ problem?

Not on my side, sadly, no, but maybe on Michael's?

> We could also ask other questions, of course, like: could Tramp use a
> process filter?  IMO these are very powerful tools and bring a
> substantial degree of freedom of implementation.  Currently Tramp relies
> on accept-p-o and then searches the process buffer for regexps.  To me,
> that just seems more difficult and error-prone than process filters.

FWIW, I believe the crux of the matter here is that process filters
receive an arbitrary chunk at a time, so we almost always need to make
them accumulate the received data into some kind of buffer-like data
structure until we have "enough" data.

IOW, most process filters need to do something like

    (lambda (proc string)
      (let* ((buffer (process-get proc 'my-buffer))
             (new (concat buffer string)))
        (if (not (had-enough-p new))
            (process-put proc 'my-buffer new)
          (process-put proc 'my-buffer nil)
          (do-the-actual-processing new))))

Another issue for Tramp is that basically all of the API it has to
implement (for `file-name-handler-alist`) is synchronous, so that forces
it to resort to `accept-p-o` :-(

If we want Tramp to work better, we'll need to provide asynchronous
versions of most of those operations (presumably using some kind of
promise/future abstraction).


        Stefan

Previous Next

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