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

Previous Next

Full log

View this message in rfc822 format

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

On Wed, Mar 15, 2023 at 9:43 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> 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` :-(

SLY, jsonrpc.el, and other code is synchronous as well (the completion
API is synch, as you well know).  `accept-p-o` + a filter that invokes
a closure that throws out of the loop is a great way to do this.
See jsonrpc-request, for example.  No JUST-THIS-ONE, and has
been working fine in many forms since Emacs 24.3 AFAIK.

> 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).

We could start with using a filter, just like the one you described above
Tramp doesn't use a filter, and I think that's part of the problem.

João

Previous Next

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