From: "João Távora" <joaotavora@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 41531@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
andreyk.mad@gmail.com
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Tue, 26 May 2020 21:00:47 +0100 [thread overview]
Message-ID: <87tv02pits.fsf@gmail.com> (raw)
In-Reply-To: <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@yandex.ru> (Dmitry Gutov's message of "Tue, 26 May 2020 22:14:31 +0300")
Dmitry Gutov <dgutov@yandex.ru> writes:
>> no idea of it. In the framework you either make the callback a noop,
>> or you set it aborted for the client to save some work. Or both.
>
> So the abort thing. In pre-command-hook?
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. Invalidation may or may not entail letting the
holder of the callback know that the previous call became invalid.
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.
> It's good to have a well-documented contract. Functions do
> _everything_. They can't be optimal for everything.
You're missing a Lisp point here. It doesn't matter if it's an CLOS
object, a struct, a function or my beautiful singing voice: it just has
to be an object which you can make unique instances of and can respond
to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf
errored-p). That's the contract. A function fits perfectly.
>>>> The future's creditor is the only one who could do that to any
>>>> useful effect. Does it have access to the process? Probably not.
>>> It can (barring any complex abstractions). It created the process,
>>> after all.
>> Not really, it asked a client to solve a problem, doesn't know how
>> the client if the client is doing by async process or cointoss.
> Seems like we're miscommunicating.
Well you implied that the creditor of the future (the caller who
received) created the process. It does not. See the patch to Stefan.
>> is a bad idea. An abort switch whose contract is "just letting you know
>> I don't need this anymore" is better. But again, in eldoc, not so
>> useful. And again, nothing to do with futures here.
>
> Here as well.
OK. The takeaway is that "aborting a future" doesn't need any constructs
specific to futures, is all.
> See above about not having to change anything.
But then we don't have to change anything in any case! I already
changed EVERY user of eldoc-documentation-functions: every single one of
the 5 in existence in the entire world. So we're all good.
>> +;; NOTE: The xref API is still experimental and can change in
>> major,
>> +;; backward-incompatible ways. Everyone is encouraged to try it, and
>> +;; report to us any problems or use cases we hadn't anticiated, by
>> +;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
>> That has been sitting there for almost three Emacs major versions
>> (in
>> fact you added it after the initial 25 release). All I'm asking is for
>> a little such flexibility with eldoc.
>
> I wrote that for xref.el because that was the state of affairs, and
> xref was relatively new. Especially compared to eldoc.
This part of eldoc.el is probably newer than xref.el was when you wrote
that.
> But we're probably miscommunicating here as well.
Doubt it.
> OK, I see your point: eldoc-documentation-functions is new. And
> apparently you don't intend to add this feature to the variable
> without "s".
Yes, exactly. eldoc-documentation-function should be obsoleted IMO.
>> It just looks like you're holding this problem hostage to introducing
>> some kind of rushed futures solution. I don't agree with either of
>> these things.
>
> Who's holding what hostage? I showed a smoother approach, you didn't
> like it. No big surprise about that.
Let me explain. First: it's clearly not "smoother", your're asking users
to wrap their heads around a function that returns a function taking a
function. That's not what I want to present to Eglot contributors, for
instance. And I'm not too crazy with presenting them this "future
thing" that is completely different from Eglot's use of Flymake,
jsonrpc.el, completion-at-point, etc... In other words, my ambition is
consistency and you seem to be denying it for reasons I can't
understand, because nothing in the steps I am taking denies _your_
ambitions, which seem to be futures. That's why I speak of "hostage".
João
next prev parent reply other threads:[~2020-05-26 20:00 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 [this message]
2020-05-27 21:14 ` Dmitry Gutov
2020-05-27 22:13 ` João Távora
2020-05-27 23:35 ` Dmitry Gutov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tv02pits.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=41531@debbugs.gnu.org \
--cc=andreyk.mad@gmail.com \
--cc=dgutov@yandex.ru \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.