From: Dmitry Gutov <dgutov@yandex.ru>
To: "João Távora" <joaotavora@gmail.com>
Cc: 41531@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
Andrii Kolomoiets <andreyk.mad@gmail.com>
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Thu, 28 May 2020 02:35:36 +0300 [thread overview]
Message-ID: <919188b1-154a-668a-7b0a-82fb96121c9e@yandex.ru> (raw)
In-Reply-To: <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@mail.gmail.com>
On 28.05.2020 01:13, João Távora wrote:
> On Wed, May 27, 2020 at 10:14 PM Dmitry Gutov <dgutov@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.
next prev parent reply other threads:[~2020-05-27 23:35 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 17:04 bug#41531: 27.0.91; Better handle asynchronous eldoc backends João Távora
2020-05-25 23:52 ` Dmitry Gutov
2020-05-26 1:21 ` João Távora
2020-05-26 13:57 ` Dmitry Gutov
2020-05-26 16:03 ` João Távora
2020-05-26 19:14 ` Dmitry Gutov
2020-05-26 20:00 ` João Távora
2020-05-27 21:14 ` Dmitry Gutov
2020-05-27 22:13 ` João Távora
2020-05-27 23:35 ` Dmitry Gutov [this message]
2020-05-27 23:57 ` João Távora
2020-05-26 2:38 ` Stefan Monnier
2020-05-26 11:22 ` João Távora
2020-05-26 14:53 ` Stefan Monnier
2020-05-26 15:19 ` João Távora
2020-05-26 15:56 ` Stefan Monnier
2020-05-26 16:26 ` João Távora
2020-05-26 17:39 ` Stefan Monnier
2020-05-26 18:49 ` João Távora
2020-06-03 2:45 ` Stefan Monnier
2020-06-03 18:07 ` João Távora
2020-06-03 20:22 ` Stefan Monnier
2020-06-03 20:36 ` João Távora
2020-06-03 21:21 ` Stefan Monnier
2020-06-05 11:26 ` João Távora
2020-06-03 21:28 ` Dmitry Gutov
2020-06-06 1:57 ` Dmitry Gutov
2020-05-26 13:32 ` Dmitry Gutov
2020-05-26 16:56 ` João Távora
2020-06-03 18:56 ` bug#41531: 28.0.50; proper Eldoc async support João Távora
2020-06-04 16:20 ` Andrii Kolomoiets
2020-06-04 18:22 ` Dmitry Gutov
2020-06-04 19:00 ` Andrii Kolomoiets
2020-06-05 22:53 ` João Távora
2020-06-05 11:00 ` João Távora
2020-06-05 17:50 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-06-05 23:25 ` João Távora
2020-06-05 23:28 ` João Távora
2020-06-11 11:11 ` Andrii Kolomoiets
2020-06-30 11:31 ` bug#41531: 27.0.91; Better handle asynchronous eldoc backends João Távora
2020-07-04 7:45 ` Eli Zaretskii
2020-07-04 9:21 ` João Távora
2020-07-04 9:31 ` Eli Zaretskii
2020-07-04 9:37 ` João Távora
2020-07-04 9:44 ` Eli Zaretskii
2020-07-04 11:00 ` João Távora
2020-07-04 21:06 ` Dmitry Gutov
2020-07-04 23:12 ` João Távora
2020-07-07 0:43 ` Dmitry Gutov
2020-07-07 10:58 ` João Távora
2020-07-07 14:18 ` Dmitry Gutov
2020-07-07 14:34 ` João Távora
2020-07-05 12:03 ` João Távora
2020-07-05 15:09 ` Eli Zaretskii
2020-07-05 15:13 ` Stefan Monnier
2020-07-04 10:04 ` Dmitry Gutov
2020-07-04 11:48 ` João Távora
2020-07-04 21:27 ` Dmitry Gutov
2020-07-04 21:30 ` Dmitry Gutov
2020-07-04 23:07 ` João Távora
2020-07-07 3:01 ` Dmitry Gutov
2020-07-07 10:56 ` João Távora
2020-07-07 12:23 ` João Távora
2020-07-07 13:38 ` Stefan Monnier
2020-07-07 14:24 ` Dmitry Gutov
2020-07-07 16:07 ` Stefan Monnier
2020-07-07 23:11 ` Dmitry Gutov
2020-07-08 3:58 ` Stefan Monnier
2020-07-08 11:20 ` Dmitry Gutov
2020-07-08 13:25 ` Stefan Monnier
2020-07-08 13:41 ` João Távora
2020-07-08 14:21 ` Dmitry Gutov
2020-07-08 15:12 ` João Távora
2020-07-08 18:32 ` Dmitry Gutov
2020-07-08 19:12 ` Eli Zaretskii
2020-07-07 14:45 ` João Távora
2020-07-07 14:40 ` Dmitry Gutov
2020-07-07 22:24 ` Dmitry Gutov
2020-07-07 22:49 ` João Távora
2020-07-07 23:00 ` Dmitry Gutov
2020-07-07 23:24 ` João Távora
2020-07-07 23:42 ` Dmitry Gutov
2020-07-07 23:46 ` João Távora
2020-07-08 0:10 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=919188b1-154a-668a-7b0a-82fb96121c9e@yandex.ru \
--to=dgutov@yandex.ru \
--cc=41531@debbugs.gnu.org \
--cc=andreyk.mad@gmail.com \
--cc=joaotavora@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).