|
From: | Dmitry Gutov |
Subject: | bug#41531: 27.0.91; Better handle asynchronous eldoc backends |
Date: | Wed, 8 Jul 2020 02:11:11 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 07.07.2020 19:07, Stefan Monnier wrote: >> But I fear we wouldn't be able to roll back the related decisions >> so easily, however.
I don't see any reason to fear that. The more time we spend discussing what the ideal should look like, the less time we have to actually get there.
Given we can't even agree on the acceptance criteria, how would the rollback process look? Another "let's get it merged, folks"?
With nobody particular in charge of Eldoc except maybe for Joao now? Who will of course be ecstatic to change the API to one he explicitly disliked in the beginning.
The current eldoc-async branch doesn't get us further from the ideal, I believe, unless `emacs-28` gets cut before we get our act together. But if we don't get our act together before `emacs-28` then the alternative is to have Emacs-28 without support for async eldoc, which I think is even worse.
Why you don't consider the alternative with less invasive changes, is beyond my understanding.
I recommend we try and be pragmatic. Especially since it will make us all happier (instead of arguing against each other, we get to work on improving the code).
I wouldn't call the definition of eldoc-print-current-symbol-info in this branch an improvement over anything.
[Prev in Thread] | Current Thread | [Next in Thread] |