bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41531: 27.0.91; Better handle asynchronous eldoc backends


From: João Távora
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Thu, 28 May 2020 00:57:56 +0100

On Thu, May 28, 2020 at 12:35 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> It's a somewhat incorrect behavior that is, however, easier to implement.

In the futures, how would you prevent a client from giving you
a stale future? You have the very same problem. Callbacks
aren't "easier" to implement than futures, either.  I'm not saying
they are "superior", as you seem to be pretending with futures,
They just happen to be the style that's most used in Emacs.

Futures are really good when you bring in continuations:
i.e. functions that can halt and resume their processing, so
you can write normally, as if there was no async, but still have
it happen automatically. But that requires an evaluator, which
is what generator.el does, and that's what enables proper
futures like the ones in emacs-aio. Anything other than
that is just moving objects and funcalls around, for style
(or lack thereof, to some people)

> Either way, that would require an additional way to signal. Try to fit
> this into your proposal. It won't match so well.

I've already shown you're mistaken.

> > Suspend this discussion?  Sure, this discussion yes, if your want.
> > But not this bugfix: that would be exactly what "holding hostage"
> > means. Don't hold this bugfix hostage: it has nothing to do with
> > futures.
>
> It's a new feature, not a bugfix.

No it's not.  Async clients are using internal functions.
eldoc-message is an internal function. eldoc is broken
for async clients, always has been. You know this, of
course. I worked on a fix and your're holding it up because
of a longing for an abstraction that you kinda like but
are still having doubts about.

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]