bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61350: Eglot over Tramp freezes with large project


From: João Távora
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@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]