GNU bug report logs - #41531
27.0.91; Better handle asynchronous eldoc backends

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>,
 41531 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, andreyk.mad <at> gmail.com
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Sat, 4 Jul 2020 13:04:35 +0300

On 30.06.2020 14:31, João Távora wrote:
> Dmitry has expressed his intent to make the new eldoc.el work with a new
> futures/promises library.  He prototyped one of those libraries.  I have
> nothing against that in the future.  However,
> 
> 1. I don't have the resources to make the eldoc.el prototype work with
>     Dmitry's or other libraries;
> 
> 2. We should revisit the purpose and the details of that and other
>     libraries in a separate discussion.  For now it's high time we
>     advance the Eldoc libray;.

Unsurprisingly, I object to this approach. We should have better async 
support in multiple Emacs facilities, and that means standardizing on 
some particular async primitives and functions that can manipulate them. 
There is no need to release support for ad-hoc async values (you didn't 
like mine, so it's only fair play that I object to yours) when we can 
transition to full futures right away.

I'll get into a little more detail in the more full review, tonight or 
tomorrow, but for now my impression is that, in the absence of such 
standard library and async manipulation functions, you decided to 
implement them specially in Eldoc. Even though most of that logic should 
be extracted to general purpose code that manipulates async objects 
(futures/promises or the like). And I wonder how the desire not to have 
such logic in Eglot has influenced your total vision of the API.

Because with futures in standard library, it could look fairly 
different, and could need fewer changes compared to its current shape.

Regarding #1, it should be trivial to reimplement on top of futures. I 
could do this myself, as long as everybody is fine with the proposed 
shape of futures on standardize on.

Previous Next

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