GNU bug report logs -
#41531
27.0.91; Better handle asynchronous eldoc backends
Previous Next
Full log
View this message in rfc822 format
On Thu, May 28, 2020 at 12:35 AM Dmitry Gutov <dgutov <at> 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
This bug report was last modified 5 years and 38 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.