From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!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, 07 Jul 2020 11:56:01 +0100 Message-ID: <877dvfiofy.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15148"; 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, 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 Jul 07 12:57:13 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 1jslHk-0003pT-Oa for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jul 2020 12:57:12 +0200 Original-Received: from localhost ([::1]:60050 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jslHj-0001QR-KB for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jul 2020 06:57:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37216) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jslHa-0001L7-G5 for bug-gnu-emacs@gnu.org; Tue, 07 Jul 2020 06:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jslHa-0000xK-5t for bug-gnu-emacs@gnu.org; Tue, 07 Jul 2020 06:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jslHa-0007gr-4U for bug-gnu-emacs@gnu.org; Tue, 07 Jul 2020 06:57:02 -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, 07 Jul 2020 10:57: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.159411937629506 (code B ref 41531); Tue, 07 Jul 2020 10:57:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 10:56:16 +0000 Original-Received: from localhost ([127.0.0.1]:35569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jslGp-0007fp-SE for submit@debbugs.gnu.org; Tue, 07 Jul 2020 06:56:16 -0400 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:46304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jslGl-0007fX-DW for 41531@debbugs.gnu.org; Tue, 07 Jul 2020 06:56:15 -0400 Original-Received: by mail-wr1-f51.google.com with SMTP id r12so44593432wrj.13 for <41531@debbugs.gnu.org>; Tue, 07 Jul 2020 03:56:11 -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=wFo82F9BYxp9h6i7nk/imamXlrR7Jt6bw9l2u15Wbww=; b=sEkMZ2OLIP4WLZJ67mb2oFsazmXs04MkTxdUN+INt7E8+fzpVl6/xFRMqdRbjkfsTU kVYBQVoy0jduDUjqRwC4UNB9Zu1pJG7UFpoZIgXnJa0O1Fz6FWNnj5oGSY29FVhqXuY1 F7QNjmCJcsWbbDg1YgCNd/5ehW8TQyY5xYg9FbZQhQgywj2Bk5u6kLfQr0eKPNAMeVeO n1H0LexF2B5udv70L8hHNmlBsO2OImfUW3ocavONhEAL9RBBifzXUaqXW7w2Bn9XTpHx 6oSc/bc+zQO/iAIRlJ6lL4i6MjlKlv1uouzk91g3lgwcY4D36+FNGFzf52KcnvX1PcVZ gDpA== 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=wFo82F9BYxp9h6i7nk/imamXlrR7Jt6bw9l2u15Wbww=; b=se+hAYrn4+Waec6HUfgxqZ3czAtQOIXlEGM1axmGROtMgcxNw1m3C4rRpjmgnU9mr2 FgJDn32Mr+1OhjwbWQf2k1ncgR4aGjC1KX3K5ShrY0ymC7eYLBzKUJaXRH5ouXK6rwEM Y7AGHunNjBYdje6jA6o3IqVq9ySEqyW5A8Lxg9VDE4fr6J06GYoAHKi5aatVqVN+2S4J lFDoxyFeP5i5YUS07pb+gt0a9z+SJQLeUqHHynKPJOo7SxZw0NTg5U/jJtSJOIUV6Flt SOHlL+jnY/mdsLcyqBVX3XLs+8Xn07XOAuBD0y7i4VuLxobKMZW87byUaMn7zbwqdrAq QVFw== X-Gm-Message-State: AOAM533N9gyHBBETQfvDMvPIldlu2x+kJ6S1u2TnvCVaam+TbvtMplL5 HcJqA9lewaK7z56k68axC6c= X-Google-Smtp-Source: ABdhPJx8/O0plSKGWR3GUtLHztOZzY+VOjO4TzInD3vL5pIHjPaFi4Ad2mkMox86/V/YG6OvSLqg7w== X-Received: by 2002:adf:f34c:: with SMTP id e12mr50934837wrp.46.1594119365300; Tue, 07 Jul 2020 03:56:05 -0700 (PDT) Original-Received: from krug (6.213.115.89.rev.vodafone.pt. [89.115.213.6]) by smtp.gmail.com with ESMTPSA id d18sm599393wrj.8.2020.07.07.03.56.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 03:56:04 -0700 (PDT) In-Reply-To: <671983cf-e4f5-f128-541b-ceac793f35e5@yandex.ru> (Dmitry Gutov's message of "Tue, 7 Jul 2020 06:01:20 +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:182778 Archived-At: 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=C3=A3o