GNU bug report logs - #41531
27.0.91; Better handle asynchronous eldoc backends

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad <at> gmail.com, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Tue, 26 May 2020 11:56:12 -0400

> It's not complete, is it?

Don't know.  I have the impression that it's complete enough to give you
the same "power" as the callback argument.

I.e. instead of (funcall BACKEND CALLBACK)
you (eldoc-future-set-callback (funcall BACKEND) CALLBACK) and instead
of (funcall CALLBACK VALUE) you (eldoc-future-set-value FUT VALUE).

> And how to I use it to solve the
> eldoc-documentation-compose problem?

AFAIK this is orthogonal to the technique we use for the backend to run
eldoc's callback code.

> I suppose it's possible, anything
> is.  But do we really want to hand-roll futures in eldoc.el when we got
> this nice https://github.com/skeeto/emacs-aio/commits/master that we
> could be looking into?

I'm not familiar with that package, so I can't judge.  It might be an
even better option, indeed.

> Also the latest patch I attach solves the eldoc-documentation-compose
> problem decently (should actually be less LOC than previous versions).
> I suggest we go with this tried-and-tested well-understood solution and
> then adjust as more sophisticated solutions come along and we evaluate
> their merits.

The use of futures has been discussed forever in the context of
several packages.  That's why at this stage, I think either we decide to
drop the idea or to start using it.
I'm OK with either option.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.