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

Previous Next

Full log

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>, 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 23:24:32 -0700

On 3/15/2023 2:49 PM, João Távora wrote:
> 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.

Assuming I understand the context here correctly, this sort of thing is 
part of why Chris Wellons' emacs-aio package uses 'run-at-time' for 
handling resolved promises[1]:

> If the result is ready call the callback in the next event loop turn using run-at-time. This is important because it keeps all the asynchronous components isolated from one another. They won’t see each others’ frames on the call stack, nor frames from aio. This is so important that the Promises/A+ specification is explicit about it.

While a solution specific to the problem in this bug likely doesn't 
require an entire asynchrony framework, if we get one into Emacs, it 
should definitely support this case. (That said, a lot of the discussion 
from this is probably best left to the emacs-devel thread so as not to 
cause too much distraction... :))

[1] https://nullprogram.com/blog/2019/03/10/

Previous Next

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