bug#41531: 27.0.91; Better handle asynchronous eldoc backends

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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 haven't seen a consistent plan "for transitioning to futures".  All
I've seen is (complicated, IMO) ideas on how to avoid the
callback-calling style by hiding the callback in an object.  I've seen
little argument or discussion of what futures are supposed to do or fix
or improve.  And I've seen no feedback from the author of what seems to
be the most promising futures library, aio.el which uses the
generator.el library, to provide, presumably, more elegant
"language-level" futures (i.e. futures that aren't only hiding the
callback in some other object).

Despite that, I've stated here repeatedly, tiringly: In principle, I
don't object to futures at all.  I just think it has to be a
thought-through change.  Propose your library to emacs-devel and let's
iterate it there.

> 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.

Of course, and that's what engineering is about.  For the most trivial
of changes X there is _always_ a refactoring R that will make
implementing X and a possible Y and Z much simpler, more elegant, more
"meta".  Knowing where to stop is what this game is about.  In this
case, there is only a vision what Y and Z might be, and a foggier vision
of how bad/good design decisions in R might affect them.

So I fixed the real, actual problem in Eldoc using the async paradigm
that is widely used in Emacs and most widely understood by programmers
of all (most?) trades: callbacks.

And, again, for the nth time, there is nothing in my code that prevents
your -- or someone else's -- "futures" library to be the nec plus ultra
of async in Emacs.  But, in the meantime, I won't let you make these
Eldoc changes hostage to your predilection for futures.  It's quite a
legitimate inclination, of course, it musn't be needlessly put it in the
way of other's work.

João