bug#41531: 27.0.91; Better handle asynchronous eldoc backends

[Dmitry Gutov]

On 04.07.2020 14:48, João Távora wrote:

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

Do you want to see the patch based on your code? It's the only 
"transition" I meant here.

If you have other questions, please ask.

> All
> I've seen is (complicated, IMO) ideas on how to avoid the
> callback-calling style by hiding the callback in an object.

Hiding is absolutely not the point.

> I've seen
> little argument or discussion of what futures are supposed to do or fix
> or improve.

I think I have described at length the very simple idea of what it is 
supposed to improve: provide a standard primitive and a library of 
composition/manipulation functions that would make these operations 
simpler. Which can be used in Emacs core, and in clients of the various 
facilities and expose future-based interfaces.

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

I'm very curious to know Christopher's opinion myself. Based on my 
experience, this will result in a much longer, protracted discussion, if 
it will result in one at all.

You seem to be in a hurry to get this in for some reason, but I'm fine 
with waiting a little more, if we get a better result.

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

If you think emacs-devel will bring more feedback, no problem.

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

The thing about refactoring, is it doesn't change observable behavior. 
Refactoring would keep the stable interface (and e.g. reuse future-based 
utility functions under the covers).

Whereas the improvement I would like to see here, would change it. So 
it's not something that could be simply moved to backlog.

And as I intent to explain later, I believe you will need 
future-manipulating functions inside eldoc client code anyway, for best 
user experience. So we might as well bite the bullet and introduce 
futures at the API level.

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

Please recall how you rejected my proposal along the same lines.

And it's fine. We can do better.

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

"won't let you" is not exactly how things work here. We usually try hard 
to reach a consensus.

In any case, I have considered this for some time, and my arguments for 
"let's work on this some more" won't be limited to futures-vs-callbacks.

> It's quite a
> legitimate inclination, of course, it musn't be needlessly put it in the
> way of other's work.

I agree that there are improvements to be made in documentation-related 
code (whether it's in Eldoc, or not), and I also think that you might 
not be going far enough in some respects.

But the problem you seem to be urgent to fix (having eldoc-message 
called from client code) is not so terrible that we can't wait until the 
future-related discussion at least has had a chance to happen.