From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends Date: Tue, 26 May 2020 17:03:46 +0100 Message-ID: <87ftbmr8d9.fsf@gmail.com> References: <875zckuet9.fsf@gmail.com> <4987863b-d390-5f87-eb1c-2cca4f4b7262@yandex.ru> <87k10zsd85.fsf@gmail.com> <384e543b-61fd-fe10-605c-b511499ecec2@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="129656"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: 41531@debbugs.gnu.org, Stefan Monnier , andreyk.mad@gmail.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 26 18:06:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdc5j-000XZF-HV for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 18:06:11 +0200 Original-Received: from localhost ([::1]:45882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdc5i-0000p4-Hf for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 12:06:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52240) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdc3e-0005sc-6m for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:04:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34695) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdc3d-0005E5-RO for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:04:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdc3d-0006Ll-Lb for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 May 2020 16:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41531 X-GNU-PR-Package: emacs Original-Received: via spool by 41531-submit@debbugs.gnu.org id=B41531.159050903824400 (code B ref 41531); Tue, 26 May 2020 16:04:01 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 26 May 2020 16:03:58 +0000 Original-Received: from localhost ([127.0.0.1]:46241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdc3Z-0006LT-Lh for submit@debbugs.gnu.org; Tue, 26 May 2020 12:03:58 -0400 Original-Received: from mail-wm1-f66.google.com ([209.85.128.66]:34509) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdc3X-0006LD-4Q for 41531@debbugs.gnu.org; Tue, 26 May 2020 12:03:56 -0400 Original-Received: by mail-wm1-f66.google.com with SMTP id u26so308556wmn.1 for <41531@debbugs.gnu.org>; Tue, 26 May 2020 09:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=cI9f1J+GfuIjdJGbEjW+fz6xOAvD28VIvKEEWidEceI=; b=B0llQ/l4s9l/UAERZAMb1s6XeQvZkcOUktjlecX5wK8zGmigEbKr2FEGo364EeRqD4 VbUT4yc3lUK9wd9H2fNJmdxZcyPSud23VQNDxkkR1Ee7L383Vxe9V4mXxe1EygUwkDHY N2fZDxCpzN6eLU9NGts+oOZqdP9ybcuPJIeQWWXqXRr60qEIImYaVk698ny2kinoVyzJ 0HafZQHT4MXcs6oLbcfE/1UhZR01zmJc4ZyI2Sj84Jb8my98VBYTpepdd3T1oPWffncM oxfBVM4jq6Nn983z8PYAfTbaPrlM0ZivlJcB7JCcSetINinogNKaerk4J8C1Peefb8ch j9RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=cI9f1J+GfuIjdJGbEjW+fz6xOAvD28VIvKEEWidEceI=; b=JpPBnX2YJvPviUVntujWE3J72COhoZoaTBpksz8mrjlzY6OoJ/cR341ABFVGWg6fDj SkndG/VqOHuo555fKnFsaBVEH4nM9lEeUq53NspiWemld9da3Pvia0HpGlXOA8oR9uyU GeYErK31GHpBjl1CST/uI+Fc7SF5EpOTpyllh7hMbApA7wqE9wyC8ga3zdeKJpmjndxL rXBBPn9hU3IBS5OqUGv4OxaQxzISY745gJh9JPiMVIXmzHMQGB/5V7+izf1jROPIwtAG ewpY3UNx1wnnCQzQjLqN1L4p2iLZ4KuTTFB77pI5qXk1Fj/xnvhRofigcb34u4lBnToH WvPg== X-Gm-Message-State: AOAM532KW+WUGIpot+bhpWo1saw3Hs8hi753Z9cAspBKn58uuA7a0E13 WDW+3BCzrLz7y3Zkt1D8+Ds= X-Google-Smtp-Source: ABdhPJzQgEEmr1vJOAI+uQVRfXDn9e2MOeR8YghOaLiN6CDsq41ltdzyY+LjaMmhbDh40vE3tvDrwA== X-Received: by 2002:a05:600c:34c:: with SMTP id u12mr2039218wmd.4.1590509029091; Tue, 26 May 2020 09:03:49 -0700 (PDT) Original-Received: from krug ([89.180.149.243]) by smtp.gmail.com with ESMTPSA id p10sm266989wra.78.2020.05.26.09.03.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2020 09:03:48 -0700 (PDT) In-Reply-To: <384e543b-61fd-fe10-605c-b511499ecec2@yandex.ru> (Dmitry Gutov's message of "Tue, 26 May 2020 16:57:13 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181047 Archived-At: Dmitry Gutov writes: > On 26.05.2020 04:21, Jo=C3=A3o T=C3=A1vora wrote: >> Dmitry Gutov writes: > They also use *special* variables? Flymake's API looks fairly clean > (you call back to REPORTER-FN, that's very reasonable), but I haven't > looked under the covers yet. REPORTER-FN, is just another name for CALLBACK. Flymake doesn't need these special variables because its API doesn't go through an old, argless shim like eldoc-documentation-function, singular. If it did, it would need a special variable, which is not such a ghoulish thing either. >> To simplify, hopefully you agree that your proposal can be summarized >> as: >> "return a function that receives a function that you >> should call with the docstring" >> whereas my proposal can be summarized as: >> "receive a function that you should call with the docstring" > > To clarify, you actually included two proposals (behavior with patch > 1, and with both patch 1 and patch 2 applied). The first one is the > one I really didn't like. The second one is better, API-wise, but will=20 > conflict with the futures-based approach. It's not a conflict at all. When you do the futures-based approach you're going to rewrite the docstring to augment the API. You do the same here: just add this to the docstring: "If you prefer, ignore CALBACK and return a `future-future' object from this function". How is that different from: "If you prefer, instead of returning a (:ASYNC . FUNCTION) cons, return a `future-future' object from this function"" ??? >> I'll leave that for later. Specifically, eldoc--handle-multiline has to >> do quite a bit more handling (to satisfy Andrey's expectations). > I'm not so such it's independent. The complexity of implementing that > would certainly vary. It is quite independent. Just look at the last patch I sent Stefan. There's only one call to eldoc--handle-multiline (in fact we could ditch it entirely). > BTW, maybe eldoc-message should handle this after all? Since it's the > last link in the chain. Or even do that in the default value of=20 > eldoc-message-function (create a wrapper for minibuffer-message). Doesn't work well becasue eldoc-message is called by both the produced _and_ the backend, as I showed you earlier. And it certainly doesn't work with eldoc-documentation-compose. >> Replying to parts from the other discussion in the Github tracker now. >>=20 >>> OK, another question: if the result still /valid/? >> ^^ Assuming you mean "is". >> Well, if the client discovers the result to be invalid, ... > > So the client will have to save and then compare the current buffer, > the value of point and buffer-chars-modification-tick now? Ah, _that_ validity. No, no, never do that. The client should have 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. >>> No idea, a hypothetical one. It's an open API, not everybody is or >>> will be using LSP until the end of time. And it doesn't really have to >>> be huge. A saving is a saving. >> There's no free lunch. A very small saving in time for more >> complexity >> is bad. That's what overengineered means. > > Futures are not particularly more complex to use. Sure, but they are _more_ complex. And you're mixing up two things: futures _aren't_ the only way -- or even a particularly easy way -- to signal to the clients that thety can give up their efforts. All the client needs to have is access to an object that's shared between it and the framework. That object _needn't_ be a first-class CLOS object or struct. It can be a function. >>> You can certainly kill the external process outside of it. Saving on >>> CPU expenses in general. >> 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. >> You would have to return a complex future with a kill switch. That's >> possible, but tricky, because you'd then have to be ready in the >> sentinel for another source of unexpected kills. > > That would be none of ElDoc's business, though. But the implementation > will get to be as complex as it needs. _That's_ why an abort switch whose contract is "kill this immediately" 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. >> Why indeed? Your other argument, that this makes the transition to >> proper futures (such as the ones in https://github.com/skeeto/emacs-aio) >> easier, is questionable, too. There are two scenarios here: >> - You want to keep backward compatibility to this API published in >> eldoc >> 1.1.0 until the time of the Emacs 28 release: > > The one thing I want to avoid doing is changing the callsig of every > documentation function, and then changing them back when we switch to=20 > futures. So _don't_ change the "callsig". If you implement futures you _are_ going to change the protocol anyway, i.e. write new stuff in the docstring. >> This is something that I -- and Stefan, if I'm not mistaken, -- don't >> think we should worry about. Just because a package is :core GNU ELPA >> doesn't necessarily mean we guarantee stability of its API. > > Um, I'm pretty sure we guarantee a fair amount of stability. That's not what Stefan said here: https://github.com/joaotavora/eglot/pull/459#issuecomment-633634034 And that's not what the Dmitry from 2016 wrote in xref.el +;; 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. >> But if we do, then we'll have to explain in the docstring that there >> is a fourth return value for the hook functions. In my version we'll >> have to do exactly the same. >> - You don't want to keep backward compatibility until Emacs 28: >> Then, when the super-futures are here, you can just kill the >> CALLBACK >> arg if we find it doesn't fit and rewrite the docstring without >> concerns. > > Kill the arg in all built-in functions, as well as in external > consumers? Yes, if we discover there aren't so many. Currently there are 5 users in Emacs proper, 0 in GNU ELPA and quite sure 0 elsewhere in the world. So 0 external consumers. Do you really think if I push my patch there will be hordes of eldoc-documentation-functions users out there using this horrible futureless API that I'm proposing? There won't, and I'm happy to add a big disclaimer to the top of the eldoc.el file. But if you really think we wouldn't be able to bring ourselves to kill the arg, then just reintroduce eldoc-documentation-callback, and kill _that_ later on. Or just don't kill the arg, period. 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. I think this particular problem shouldn't be held hostage to rearchitecting async in Emacs, laudable and useful a goal as that might be. And I think a futures library should be well thought out: I'd like to discuss this in emacs-devel, at least get some opinions on Christopher Wellon's solution, which seems very elegant. In the meantime, I have a working patch that follows current coding practice, solves this problem and in no way prevents or interferes with future work. Anyway, see the patch I sent to Stefan. Jo=C3=A3o