|
From: | Dmitry Gutov |
Subject: | bug#41531: 27.0.91; Better handle asynchronous eldoc backends |
Date: | Sat, 4 Jul 2020 13:04:35 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |