bug#41531: 27.0.91; Better handle asynchronous eldoc backends

[Dmitry Gutov <dgutov@yandex.ru>]

On 26.05.2020 23:00, João Távora wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>>> no idea of it.  In the framework you either make the callback a noop,
>>> or you set it aborted for the client to save some work.  Or both.
>>
>> So the abort thing. In pre-command-hook?
> 
> No, the creditor of the future or issuer of the callback aborts or
> invalidates the previous version just before issuing a new one. Nothing
> pre-command-hook here.

Where/when would eldoc-mode do it?

> Invalidation may or may not entail letting the
> holder of the callback know that the previous call became invalid.

Letting know the issuer of the future, you mean.

> Flymake does this: by invoking a backend again with a new callback
> instance it is signalling that the preceding one became invalid.  If the
> backend tries to call the previous callback, it is an error and the
> backend is disabled.

Worse is sometimes better, we know.

>> It's good to have a well-documented contract. Functions do
>> _everything_. They can't be optimal for everything.
> 
> You're missing a Lisp point here.  It doesn't matter if it's an CLOS
> object, a struct, a function or my beautiful singing voice: it just has
> to be an object which you can make unique instances of and can respond
> to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf
> errored-p).  That's the contract.  A function fits perfectly.

That would be my "alternative" suggestion: for 
eldoc-documentation-functions elements to return a function (denoted as 
FETCHER in the docstring) if they want the async convention.

>>>>> The future's creditor is the only one who could do that to any
>>>>> useful effect.  Does it have access to the process?  Probably not.
>>>> It can (barring any complex abstractions). It created the process,
>>>> after all.
>>> Not really, it asked a client to solve a problem, doesn't know how
>>> the client if the client is doing by async process or cointoss.
>> Seems like we're miscommunicating.
> 
> Well you implied that the creditor of the future (the caller who
> received) created the process.  It does not.  See the patch to Stefan.

Okay, creditor != creator. But what you've said a few messages back 
(seen at the top of the quotes chain above) doesn't make sense: the 
creditor will call (future-abort fut), and the issuer of the future can 
make sure that this operation will indeed kill the process.

That's the main idea behind aborting futures. Or canceling. Whatever 
term we're going to pick.

>> See above about not having to change anything.
> 
> But then we don't have to change anything in any case!  I already
> changed EVERY user of eldoc-documentation-functions: every single one of
> the 5 in existence in the entire world.  So we're all good.

And then we'll need to change them back. And in the meantime, the new 
convention could get external users (some people do live on the bleeding 
edge), and this will get messier.

>> OK, I see your point: eldoc-documentation-functions is new. And
>> apparently you don't intend to add this feature to the variable
>> without "s".
> 
> Yes, exactly.  eldoc-documentation-function should be obsoleted IMO.

Perhaps. I'm also not buying the usefulness of eldoc-documentation-compose.

>>> It just looks like you're holding this problem hostage to introducing
>>> some kind of rushed futures solution.  I don't agree with either of
>>> these things.
>>
>> Who's holding what hostage? I showed a smoother approach, you didn't
>> like it. No big surprise about that.
> 
> Let me explain. First: it's clearly not "smoother", your're asking users
> to wrap their heads around a function that returns a function taking a
> function.  That's not what I want to present to Eglot contributors, for
> instance.

Would they need to? As soon as an existing Eglot's implementation is in 
place, that exact part of the code wouldn't need to be touched often.

In any case, you are over-exaggerating. This exact design has been a 
part of "asynchronous" backend calling convention in Company for years. 
And not once have I seen a complaint that it's overly complex.

> And I'm not too crazy with presenting them this "future
> thing" that is completely different from Eglot's use of Flymake,
> jsonrpc.el, completion-at-point, etc...

Didn't you say that Flymake could use futures as well?

> In other words, my ambition is
> consistency and you seem to be denying it for reasons I can't
> understand, because nothing in the steps I am taking denies _your_
> ambitions, which seem to be futures.  That's why I speak of "hostage".

See above. But perhaps we should after all suspend this discussion until 
we had a chance to reach a better mutual understanding of the futures 
API, and how we expect it to help (or not). I promise to show some 
proposals in the near future.