[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41531: 27.0.91; Better handle asynchronous eldoc backends
From: |
João Távora |
Subject: |
bug#41531: 27.0.91; Better handle asynchronous eldoc backends |
Date: |
Tue, 26 May 2020 21:00:47 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) |
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
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, João Távora, 2020/05/25
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, Dmitry Gutov, 2020/05/25
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, João Távora, 2020/05/25
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, Dmitry Gutov, 2020/05/26
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, João Távora, 2020/05/26
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, Dmitry Gutov, 2020/05/26
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends,
João Távora <=
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, Dmitry Gutov, 2020/05/27
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, João Távora, 2020/05/27
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, Dmitry Gutov, 2020/05/27
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, João Távora, 2020/05/27
bug#41531: 27.0.91; Better handle asynchronous eldoc backends, Stefan Monnier, 2020/05/25
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, João Távora, 2020/05/26
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, Stefan Monnier, 2020/05/26
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, João Távora, 2020/05/26
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, Stefan Monnier, 2020/05/26
- bug#41531: 27.0.91; Better handle asynchronous eldoc backends, João Távora, 2020/05/26