From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends Date: Tue, 07 Jul 2020 09:38:45 -0400 Message-ID: References: <875zckuet9.fsf@gmail.com> <87sgecssch.fsf@gmail.com> <87tuynsdp6.fsf@gmail.com> <5d768a69-3574-10c5-e80a-8ab77ec60462@yandex.ru> <87h7umop62.fsf@gmail.com> <671983cf-e4f5-f128-541b-ceac793f35e5@yandex.ru> <877dvfiofy.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27329"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 41531@debbugs.gnu.org, andreyk.mad@gmail.com, Dmitry Gutov 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 Jul 07 15:40: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 1jsnpS-0006yM-VT for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jul 2020 15:40:11 +0200 Original-Received: from localhost ([::1]:42536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jsnpS-00064z-1L for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jul 2020 09:40:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jsnpK-00064a-Na for bug-gnu-emacs@gnu.org; Tue, 07 Jul 2020 09:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52458) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jsnpK-00042C-EP for bug-gnu-emacs@gnu.org; Tue, 07 Jul 2020 09:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jsnpK-0005Ux-CI for bug-gnu-emacs@gnu.org; Tue, 07 Jul 2020 09:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jul 2020 13:40:02 +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.159412914221065 (code B ref 41531); Tue, 07 Jul 2020 13:40:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 13:39:02 +0000 Original-Received: from localhost ([127.0.0.1]:35771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jsnoL-0005TQ-O1 for submit@debbugs.gnu.org; Tue, 07 Jul 2020 09:39:02 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48936) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jsnoG-0005T9-4k for 41531@debbugs.gnu.org; Tue, 07 Jul 2020 09:39:00 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E4C1100E87; Tue, 7 Jul 2020 09:38:50 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 628BC1005A8; Tue, 7 Jul 2020 09:38:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1594129127; bh=KIevi42Yxm8vrvACP2tc7Ba9zbra3LiOkiKGtvpxqPI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=hbA/pIZH1U2TfF8IsN8TNdYsAoSZC2jjzpD6QmgcTk1kupoXq7B6Oc4luBCkjTSgi By9PsBXRPTHMAz6xkbogYZXgjqAUhZ+VBOfblb+DNkIpNSeGpty0zaLR1zSH1ecQDW i0RO8/HCO7jB+j6Ck5px5pw1Z0F+4bpnQr9ESsPSMIonlAkAdoK6ijoirt/qY+1EbT KUmJ1DKDzZRKfDeZ6kBryImM4vGoYmjxA0oTtLxsE+zFIEo4N1mwJnBfKkWZ2p/CLT EX0X/CMWC6PrrSbeuKuKduRDW0MOXIZ8RXkCr69g04S5keNHtTNBYMU5x6oyru7ccv 5sjk0jB0+Xqyw== Original-Received: from alfajor (unknown [157.52.0.200]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D29B1120329; Tue, 7 Jul 2020 09:38:46 -0400 (EDT) In-Reply-To: <877dvfiofy.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 07 Jul 2020 11:56:01 +0100") 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:182782 Archived-At: [ Sorry I can't really take part in the discussion, 'cause it's a rather busy time here. ] [ The discussion is becoming too tense for my taste. Please take a break and think whether all this is important enough to warrant criticizing each other this way. I think you're both great hackers whose opinion and expertise I value very much. ] I think getting async support for eldoc is more important than *how* we get it. I suggest we install the current eldoc-async code into `master` and in parallel work quickly on a futures/promises/aio/... package for `master`. As long as it's done before we cut the `emacs-28` branch, I can't see any reason why we couldn't change the new (and hence not yet released, except for the GNU ELPA package) API in a backward-incompatible way (just like the eldoc-async already does). Stefan Jo=E3o T=E1vora [2020-07-07 11:56:01] wrote: > Dmitry Gutov writes: > >> Please don't make it sound as if I'm the only one here having a strong >> opinion about proposed code. You disregarded the simple solution in=20 >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531#8, and then went > > Are you in any way trying to say that you presented a "simple solution" > that somehow magically solves the problems of Eldoc? If you do, you're > living in conflict with reality. > > There is the problem to be solved. And then there are techniques for > solving the problem. These are two entirely separate things. To be > absolutely clear: you have not, ever, proposed an alternate solution to > the Eldoc async _problem_. > > You talked and talked and presented your favourite async handling > techniques, like having functions return functions that return > functions. You contented that I -- not you -- should work with it to > solve the problem. > > Callbacks, futures, promises, ad-hoc or proper, are just techniques. I > tried a couple techniques, including a basic futures-based one proposed > by Stefan. I didn't find any as compelling as the simplest and most > widely used in Emacs: callbacks. > > For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE: I > just don't use these Eldoc fixes to shoehorn something rushedly into > Emacs. Make a new thread, or join the existing one: > > https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00935.html > > Afterwards, propose a change to the technique, not only in Eldoc but > elsewhere, too. This idea is so simple that it boggles the mind that > you don't grasp it. > >> urgent endeavor. E.g., Flymake is stable, and I don't have any >> particular bugs in mind that need solving. > > Great. I'll just note here that it uses exactly the same technique I'm > proposing in Eldoc to communicate with multiple backends: it's curious > how that doesn't bother you. I would reasonably expect "futures" or > something else its implementation much simpler too. > >> Aside: given that this discussion has user interface in mind, it needs >> more consideration of actual user experiences we'd want to allow. Ones=20 >> not provided by eldoc itself as well. For instance, I think we sooner >> or later should have a callsig floating popup (in the vein of MS's >> editors) as an alternative to showing the signature in the echo area >> only. > > That is addressed in a comment in eldoc-docs > > ;; Finally, output to the echo area. We handle the > ;; `truncate-sym-name-if-fit' special case first, by selecting a > ;; top-section of the `*eldoc' buffer. I'm pretty sure nicer > ;; strategies can be used here, probably by splitting this > ;; function into some `eldoc-display-functions' special hook. > > I agree there is ample space for improvement, including a=20 > "floating popup" (which I wouldn't limit to callsigs though). Make > another bug report to study this. > >> The new API is incompatible with the previous one, it requires >> changing a lot of functions (though admittedly in a minor way). > > This is demonstrably false. As I've explained to Eli there is no > incompatibility in practice. 0 (zero) third-party extensions make use > of the protocol being changed from Eldoc 1.0.0 to Eldoc 1.1.0, unless > you're stalling here to secretly work on one. > > But if we really, really wanted to, it's easy to get rid of the > arguments, too, with a variation to the callback technique. I just > don't think it's worth it: a technique is a technique. > >> is easy to miss, as evidenced by describe-char-eldoc which still >> doesn't accept any arguments. > > Oh, an actual useful comment! Easily solved, thanks. And it was only > "missed" because it wasn't used anywhere. > >> Whereas we could limit ourselves to the change which would only make >> the clients use the different hook (or keep using the old one, for >> compatibility with older Flymake/Emacs versions). > > Compatibility to the old `eldoc-documentation-function' protocol is > fully guaranteed. > >> The choice to require a return of a non-nil value if the callback is >> going to be used is also kinda odd (+1 control flow to test). What's >> the problem with using the callback synchronously if the doc is >> available right away? > > Nothing, you can do it. As long as you return non-nil, non-string. But > if you are are going to synchronously call the callback on a string, you > might as well return that string, just seems simpler. > >> The decision to double down on having different >> eldoc-documentation-strategy values seems odd to me in several >> respects. >> >> First of all, if I understand the main motivation behind it, it's to >> delegate the implementation of asynchronous primitives to Eldoc. > > It's rather to make clients don't worry about the synchronization. Not > specifically to make Eldoc worry about it. As soon as you and others > come up with the uber-async library, I think Eldoc and Flymake and many > others will be very pleased to delegate work to it. > >> We don't want to bother with that in Eglot, etc. But you mentioned "a >> type of docstring" to be returned in the discussion (and the callbacks >> have the plist argument as a future proofing). If the type is a >> buffer, its contents might as well be created from several async calls > > If you want to support "buffers" as a "type of docstring", just do that: > make buffers a type of docstring. The obvious way is to have multiple > sources produce multiple buffers. > > Thing: why would you ever want to put buffer-joining complexity in the > client? They're not in the business of doing async gymnastics, they're > in the business of serving things coming from servers as efficiently and > effectively as possible. > >> , which would require the same async primitives (though rather in >> general purpose form) available on the client anyway. Though it >> doesn't seem to be necessary for LSP in common operations, it's >> unlikely to be the only such protocol we'd ever want to support. > > I don't know about that, but if we did, the current mechanism work > nicely for the example you presented. > >> The strategies themselves: >> >> - eldoc-documentation-enthusiast: What's the difference compared to >> the 'default' one? Sacrificing CPU load for lower latency? It's an odd >> choice to force the user to make. The only people who can make an >> ideal decision regarding this are probably the authors of >> eldoc-documentation-functions, but it wouldn't help if >> eldoc-documentation-functions has functions coming from different >> authors, facilities, etc. > > Has nothing to do with CPU. This is the way Eglot works now, or at > least tries to: there are two delayed doc-producing backends, and > neither is guaranteed to complete. One has priority over the other (and > special hooks are a decent, standard Emacs way to manage priority) > > Eglot shows the lower-priority one if it shows it can survive for more > than x seconds (currently x =3D 0.3, uncustomizable). No more doc > blinking. > >> - eldoc-documentation-compose: Okay, this is kinda interesting (though >> not essential), > >> I think the only reasonably predictable behavior would be to truncate >> each of them to one line, always. > > That's a display problem, not a composition problem For now it works OK > for one liners and also multiple multi-liners. Displaying doc is not > the main goal of these patches, there is certainly room for improvement, > as I said above. > >> - eldoc-documentation-compose-eagerly: Ooh, now I think I see why >> Returning futures instead (when async is needed) would provide this >> kind of guarantee without the seeming duplication of signals. > > Can't let go of that futures drum, can you? It'd be a pleasure to see > you walk the walk. > >> On a related note, I believe some facilities might want to use only >> certain "kinds" of documentation functions (as indicated by the plist=20 >> arguments). If the plist is only provided together with the response, >> there is no way to avoid unnecessary computations (e.g. making HTTP=20 >> requests that return some other kinds of values). If the plist was >> returned together with a future value, however, it would be easy to >> do, as long as we document that the futures should start the >> computation until a callback is provided (if possible, at least). > > Save it for your future futures implementation. > >> And in a different high-level argument: you stated that you intend to >> have Eglot use a non-default value of eldoc-documentation-strategy.=20 > > OK, but this has nothing to do with Eldoc, does it? Make a bug report > for Eglot, I'll explain why it does this, and maybe I'll change it.. > >> Next, eldoc-print-current-symbol-info is a mess, very hard to >> follow. I am frankly offended that you argued that both ad-hoc futures > > I meant no effense. > >> idea). This should very well be possible to untangle in the future, >> but I'd rather not have code like this in Emacs if we can help it. > > You're such an ace programmer that you code alternatives that are so > brief that they occupy no code at all! > >> Further, having all strategies basically delegate to hardcoded options >> inside eldoc-print-current-symbol-info seems to confirm that the set >> of available strategies is a closed one. Which is not what I would >> expect from a variable called eldoc-documentation-strategy. > > There are four strategies to choose from but you can make more. What > did you have in mind?=20=20 > >> These are my objections, for now. I'll have to study >> eldoc--handle-docs a bit later, but any problems it has are probably >> orthogonal to the rest of the list. > > Thanks. > > Jo=E3o