From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends Date: Tue, 26 May 2020 22:14:31 +0300 Message-ID: <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@yandex.ru> References: <875zckuet9.fsf@gmail.com> <4987863b-d390-5f87-eb1c-2cca4f4b7262@yandex.ru> <87k10zsd85.fsf@gmail.com> <384e543b-61fd-fe10-605c-b511499ecec2@yandex.ru> <87ftbmr8d9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="95621"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: 41531@debbugs.gnu.org, Stefan Monnier , andreyk.mad@gmail.com To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 26 21:16:04 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 1jdf3R-000NrJ-W2 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 21:16:02 +0200 Original-Received: from localhost ([::1]:43530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdf2n-00048A-H0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 15:15:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdf2U-00047k-E7 for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 15:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34844) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdf2U-0007pB-40 for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 15:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdf2T-0002NP-V7 for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 15:15:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 May 2020 19:15: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.15905204869099 (code B ref 41531); Tue, 26 May 2020 19:15:01 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 26 May 2020 19:14:46 +0000 Original-Received: from localhost ([127.0.0.1]:46390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdf2E-0002Mh-3B for submit@debbugs.gnu.org; Tue, 26 May 2020 15:14:46 -0400 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:37948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdf28-0002MO-2l for 41531@debbugs.gnu.org; Tue, 26 May 2020 15:14:44 -0400 Original-Received: by mail-wr1-f52.google.com with SMTP id e1so21591948wrt.5 for <41531@debbugs.gnu.org>; Tue, 26 May 2020 12:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wNUlAVh+byE4GVU7DSGyAc6JfvSwOICisVScZZ+D/Ic=; b=JArWoVfXjXSHiOnMZkj6GTHK3PKd78O8jHFeeo2JNOHgT+qWNspZUHGHdsAa/fXVUS hXWvu803rLSk98b/QXAVjaATNw/1MZc/FvLX3MU/uFhlnLTwxTUaWUsx5L/gagBat86B 5tkwZAXnNKd5GCstJ+si+FPGPh+6VZUe0eFK4DenRtGRDHt3rdOog78akCRJ6PMhfkmB Pku4ZpeWAqQJ5gcdHVJtY6noVYCAkbfXzh6elSoPIxpobo/zgTWtZpiQ6r8l7dDYTUO0 FfEweWGpY7bw0wgeqxfotM838wN2q33kJozhUai5bZMMQ07FNEI6fP32Hq97mAjOl40K DP4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wNUlAVh+byE4GVU7DSGyAc6JfvSwOICisVScZZ+D/Ic=; b=HUQKaUPb/2+R1R0LqchDqP+44rjvQruo9KTYNHyYgtQDnJKI71DW9dPGwbgimPjySm vVRhqtjFnraj69BSZYUVvos2Cd443C8PAtBOdejyZaisEdRVcOrK4f0z86lXllk9+iwy QWN9jySnpIBB1oIIFknZfCbIOAhBiz/jQe8vfBntq8EcQcUbxXaPTnCj3I6T4caq9dzI cpK+odtjjUxx0iCNH99zdwfisEscKOCr8Ng5PcuDJzz2II+Xfv75096eHClHuNcHP4qg lXRySFWu9R8fJgEtYPljurDwrRvOuXKkbBx8CT1suF0yLAYVIdubB2Hfj1rbCqsIkjSo g1gQ== X-Gm-Message-State: AOAM531AoRZXZB7JzT9NpLuOpLr8r8drbDBdm3PsPCV2BDEFid4tDYfJ PPSx9rGBTSNKNg8gjLdXgYE= X-Google-Smtp-Source: ABdhPJx5haLX+fJZhAV3cGu8tmmbs/ArxE/JIbRnyH4FrMFYN86Uqczk5O10kEcYJU4M6xs0kruaKg== X-Received: by 2002:adf:f651:: with SMTP id x17mr22656210wrp.277.1590520474022; Tue, 26 May 2020 12:14:34 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id w15sm399520wmi.35.2020.05.26.12.14.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 12:14:33 -0700 (PDT) In-Reply-To: <87ftbmr8d9.fsf@gmail.com> Content-Language: en-US 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:181067 Archived-At: On 26.05.2020 19:03, João Távora wrote: >>> 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 >> 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"" > > ??? We're not going to do either. The :async option is only for those tho need async _right this second_. It would be fully replaced by the "futures" option. Or we can implement it right now. And hopefully we won't have to maintain the eldoc-specific futures "forever" either. >> 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 >> 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. We could split it apart, I guess. Or make two versions. >>> Replying to parts from the other discussion in the Github tracker now. >>> >>>> 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. So the abort thing. In pre-command-hook? >>>> 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. It's good to have a well-documented contract. Functions do _everything_. They can't be optimal for everything. And this way we don't add extra arguments, so whoever doesn't need async, doesn't need to change a thing. >>>> 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. Seems like we're miscommunicating. >>> 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. Here as well. >>> 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 >> 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. See above about not having to change anything. >>> 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. I wrote that for xref.el because that was the state of affairs, and xref was relatively new. Especially compared to eldoc. But we're probably miscommunicating here as well. >>> 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. 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". > 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. > 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. We should certainly take a look at it. But the built-in futures don't have to provide all the options. Just be functionally compatible. Christopher could pick up from that.