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

Previous Next

Full log

Message #62 received at 41531 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Thu, 28 May 2020 02:35:36 +0300

On 28.05.2020 01:13, João Távora wrote:
> On Wed, May 27, 2020 at 10:14 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>>> No, the creditor of the future or issuer of the callback aborts or
>>> invalidates the previous version just before issuing a new one. Nothing
>>> pre-command-hook here.
>>
>> Where/when would eldoc-mode do it?
> 
> In the idle timer function.  That's when it decides it wants
> new info, and so any old info that hasn't arrived yet is probably
> out of date.

Then eldoc might shows some info when it's no longer pertaining to the 
context around the point.

> But I think I understnad what you mean pre-command-hook.
> You suggested pre-command-hook because that's where you
> can check if point is far enough away from the place where
> the original request originated?

Or always abort, as soon as the user invokes the next command.

>>> Flymake does this: by invoking a backend again with a new callback
>>> instance it is signalling that the preceding one became invalid.  If the
>>> backend tries to call the previous callback, it is an error and the
>>> backend is disabled.
>>
>> Worse is sometimes better, we know.
> 
> That is a very confusing statement.

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

Which is fully along the lines of Richard P. Gabriel's "The Rise of 
Worse Is Better".

>> That would be my "alternative" suggestion: for
>> eldoc-documentation-functions elements to return a function (denoted as
>> FETCHER in the docstring) if they want the async convention.
> 
> They need to _receive_ an object produced externally, somhow.
> If they return a function as youv suggest, they are only doing so
> they can later _receive_ another object.  This is needlessly
> complicated.  To receive objects in some place, just use argument
> the argument list of that place.

"Returning a value" is meaningful semantic. Even when that value is a 
function.

>> Okay, creditor != creator. But what you've said a few messages back
>> (seen at the top of the quotes chain above) doesn't make sense: the
>> creditor will call (future-abort fut), and the issuer of the future can
>> make sure that this operation will indeed kill the process.
> 
> No, it does make sense. Read it again. What you're saying is what I
> meant.

Perhaps you could have agreed then.

> But that still means that the process sentinel will have to deal
> with out-of-band kills that it must distinguish from other out-of-band
> kills (such as, say, a kill -9 from the shell). That is added complexity.

It's their choice. Some processes might run too long in certain cases. 
So that would be a safeguard.

> It is better, in my opinion, to make this softer.  Let the creditor
> signal, I don't need this anymore, and the issuer will take appropriate
> measures synchronously, i.e. in the process filter and not in the
> process sentinel.

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

>> That's the main idea behind aborting futures. Or canceling. Whatever
>> term we're going to pick.
> 
> But, again, nothing you're describing here can't be implemented
> with passing a callback in the arglist. It's independent.  Futures
> particularly the versions you and Stefan are proposing are just
> other places to type basically the same sexps.  They're a stylistic
> change over callbacks, but nothing more, fundamentally.

Hence my request to wait a little.

Stefan suggested the simplest version because it both fits your current 
requirements, and it can be extended without breaking that usage.

>> Perhaps. I'm also not buying the usefulness of eldoc-documentation-compose.
> 
> Yeah,I don't get it particularly, either.  I mean, I can see its uses.
> but I'm glad you're finally getting the overengineered feeling :-)

No "finally", that was my opinion of it from the outset.

> And it's waay more useful than futures here.

Way to extend the bridge and then kick it down.

>> Would they need to? As soon as an existing Eglot's implementation is in
>> place, that exact part of the code wouldn't need to be touched often.
> 
> Code is read much, much more than is is written.  And WTF per minute
> _are_ a measure of code quality.  I would like to avoid this particular
> WTF please.

Okay, here's another argument: "Promise", or a "Future", or "Deferred" 
or whatever, are common notions across many programming languages now.

When a programmer encounters an idea familiar to them, they understand a 
program more easily. No WTFs.

>> In any case, you are over-exaggerating. This exact design has been a
> 
> "over-exaggerating".  Very meta.

Plain English.

>> And not once have I seen a complaint that it's overly complex.
> 
> Anyway, count one now.  Or don't.  I mean, I really dislike
> company-backends throughout, but I don't use it, either.

Noted.

> I mean
> I know you inherited it and I had to hack on it to add flex support
> for the capf thing, but it's a strange re-implementation of functions
> to have one single function that does wildly different things based
> on one argument.   I guess at the time there weren't generic
> functions. And the cons :async thing is equally confusing to me.
> Sorry to be frank. But I guess some people will love it, for some
> equally legitimate reason: it will seem "right" to them, or "clever".

It's very simple. Much simpler than generic functions or c-a-p-f.

So I'm surprised to see you disparage both ideas (one simpler than what 
you do, another a tiny bit more complex) as complex and outlandish.

>> Didn't you say that Flymake could use futures as well?
> 
> It could, sure, especially if you have a thousand futuristic devs
> itching to write backends but not grokking callbacks.  But let's
> not kill the existing API, please.

Probably not. Unless we find a good use in it for the extra capabilities 
provided by futures.

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

Previous Next

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