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

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 41531 <at> debbugs.gnu.org, eliz <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>, andreyk.mad <at> gmail.com
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Sun, 05 Jul 2020 00:07:01 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> [that is the] "transition" I meant here.
>
> If you have other questions, please ask.

If it wasn't clear, my suggestion is that you send your earlier
dimtry-futures.el (as I am temporarily dubbing it, for clarity) to
emacs-devel, along with a rationale for why it is needed and where it
can be useful, not only in eldoc.el but in other places in Emacs that
use callbacks like like url.el, flymake.el, jsonrpc.rl, timers,
completion, processes, etc.  You may want to include a short comparison
to Christopher Wellon's aio.el, if you have studied it.

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

Maybe I missed something, but I don't consider our discussion an
at-length discussion.  It might have been verbose, but it wasn't
in-depth at all.  And certainly it didn't involve anywhere enough people
for such an ambitious feature.  I have some comments to your last
proposed dmitry-futures.el, but this bug report is not the place to make
them.

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

I want to fix longstanding problems in Eglot.  I have limited resources,
mainly time.  It is you who seem intent on not letting this go in, as if
you won't be able to prove that "better result" after it does.  This is
absurd: if you do show it to be better, then we should migrate eldoc.el
etc to futures.  ...as I've said a trillion times already at this point.

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

I don't remember your proposal fixing anything in eldoc.el, you merely
suggested I experimented with a technique.  Which I actually did, and I
didn't see any advantage in it.

> And it's fine. We can do better.

I'm sorry you don't like my work.  I had good feedback about it.  If
_you_ can do better, I'm not stopping you.

>> 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 my book, there's nothing legitimate in vetoing a bugfix because of
some yearning for some particular abstraction or programming paradigm.
That's as absurd as demanding Emacs be rewritten in my paradigm/language
of choice before anyone else commits anything.  Especially when, for the
quadrillionth time, there is nothing stopping you from making your case
for futures after the bug is fixed.

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

In that case, if indeed they are not futures-vs-callbacks, are they
_serious_ objections?  Can they not be fixed afterwards?  I would have
expected some manifestation of them already, but you seem to waste all
your energy on your proclivity for futures.  But very well then, let's
have those non-futures objections in this bug report, the sooner the
better.

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

I've explained repeatedly: this is holding up multiple things in Eglot.
I want Eglot to serve diagnostic messages, and various kinds of
automatically gathered information about the "things at point" all
through eldoc.el.  Then move on to better stuff, of which there is a lot
in LSP, as you well know.  Also, this fixes SLY and SLIME too, both
hacking their way through eldoc.el.  Possibly the same for CIDER and
other such extensions.  This also opens up eldoc.el in non-async
situations as well, such as elisp-mode.el.  Just read the patch.

Look, Dmitry, think clearly: I'm going to fix eldoc.el and you can have
your futures.el discussion when you want, a discussion where don't know
if I'll be able to participate, but that shouldn't prevent it from
happening.  After that discussion, whatever conclusion you, possibly me,
and other interested parties arrive at, as long as you/we keep Eglot and
SLY functional, or suggest improvements to them, I'll abide.

João

Previous Next

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