bug#41531: 27.0.91; Better handle asynchronous eldoc backends

["João Távora" <joaotavora@gmail.com>]

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.  Invalidation may or may not entail letting the
holder of the callback know that the previous call became invalid.
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.

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

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

>> is a bad idea.  An abort switch whose contract is "just letting you know
>> I don't need this anymore" is better.  But again, in eldoc, not so
>> useful.  And again, nothing to do with futures here.
>
> Here as well.

OK. The takeaway is that "aborting a future" doesn't need any constructs
specific to futures, is all.

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

>>     +;; NOTE: The xref API is still experimental and can change in
>> major,
>>     +;; backward-incompatible ways.  Everyone is encouraged to try it, and
>>     +;; report to us any problems or use cases we hadn't anticiated, by
>>     +;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
>> That has been sitting there for almost three Emacs major versions
>> (in
>> fact you added it after the initial 25 release).  All I'm asking is for
>> a little such flexibility with eldoc.
>
> I wrote that for xref.el because that was the state of affairs, and
> xref was relatively new. Especially compared to eldoc.

This part of eldoc.el is probably newer than xref.el was when you wrote
that.

> But we're probably miscommunicating here as well.

Doubt it.

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

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

João