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

Previous Next

Package: emacs;

Reported by: João Távora <joaotavora <at> gmail.com>

Date: Mon, 25 May 2020 17:05:01 UTC

Severity: normal

Found in version 27.0.91

Full log


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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 41531 <at> debbugs.gnu.org,
 João Távora <joaotavora <at> gmail.com>, andreyk.mad <at> gmail.com
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Wed, 8 Jul 2020 02:11:11 +0300
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.




This bug report was last modified 5 years and 38 days ago.

Previous Next


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