bug#41531: 27.0.91; Better handle asynchronous eldoc backends

[João Távora]

[  Christopher, I'm CC-ing you in this discussion becasue we've been
discussing adding futures to Emacs, and I came across your aio.el
library which seems very promising.  (I am, however, proposing a
pragmatic intermediate solution to the particular problem in the subject) ]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It's not complete, is it?
>
> Don't know.  I have the impression that it's complete enough to give you
> the same "power" as the callback argument.

> I.e. instead of (funcall BACKEND CALLBACK)
> you (eldoc-future-set-callback (funcall BACKEND) CALLBACK) and instead
> of (funcall CALLBACK VALUE) you (eldoc-future-set-value FUT VALUE).

It is, yes.  The code is clear, not transcendental at all.  But writing
docstrings is hard.  In fact, it's possibly the hardest part of the
game.  Tell you what: you write the docstring for
eldoc-documentation-functions, I'll do the implementation.

Deal?

>> And how to I use it to solve the
>> eldoc-documentation-compose problem?
>
> AFAIK this is orthogonal to the technique we use for the backend to run
> eldoc's callback code.

Not really.  A "proper" futures library will have primitives that handle
this very elegantly.  I.e. a future that depends on multiple futures, a
future that applies a function to the first available future.  The kind
of stuff I'm sure you'll love, academically.  That would be the thing to
use there, otherwise we're just playing legos with structs and
functions.

>> I suppose it's possible, anything
>> is.  But do we really want to hand-roll futures in eldoc.el when we got
>> this nice https://github.com/skeeto/emacs-aio/commits/master that we
>> could be looking into?
>
> I'm not familiar with that package, so I can't judge.  It might be an
> even better option, indeed.

I believe it has such functionality that I mentioned before.  And then
some.  I don't understand it filly but it seems nicely coded, has two
authors that have (99% sure) assigned copyright.  The library calls
futures "promises", by the way.

>> Also the latest patch I attach solves the eldoc-documentation-compose
>> problem decently (should actually be less LOC than previous versions).
>> I suggest we go with this tried-and-tested well-understood solution and
>> then adjust as more sophisticated solutions come along and we evaluate
>> their merits.
> The use of futures has been discussed forever in the context of
> several packages.  That's why at this stage, I think either we decide
> to drop the idea or to start using it.

> I'm OK with either option.

Black and white, do or die? Nah, I don't buy it :-)

Let me be honest: the thing I'm not crazy about in futures is that if we
go the handrolled eldoc.el route that creates another distraction to
maintain separately.  Eldoc's problem lie elsewhere.

Let's use futures in the new completion API thingy, or in an elisp json
library, where they might brutally speed up parsing, by doing parsing
only parts of the document that users access.

João