From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends Date: Tue, 7 Jul 2020 06:01:20 +0300 Message-ID: <671983cf-e4f5-f128-541b-ceac793f35e5@yandex.ru> References: <875zckuet9.fsf@gmail.com> <87sgecssch.fsf@gmail.com> <87tuynsdp6.fsf@gmail.com> <5d768a69-3574-10c5-e80a-8ab77ec60462@yandex.ru> <87h7umop62.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="blaine.gmane.org:116.202.254.214"; logging-data="29873"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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 Jul 07 05:02:10 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 1jsds2-0007e8-93 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jul 2020 05:02:10 +0200 Original-Received: from localhost ([::1]:43796 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jsds1-0008Tn-7L for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jul 2020 23:02:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jsdru-0008TO-6i for bug-gnu-emacs@gnu.org; Mon, 06 Jul 2020 23:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51919) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jsdrt-00083C-Tm for bug-gnu-emacs@gnu.org; Mon, 06 Jul 2020 23:02:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jsdrt-0001px-RZ for bug-gnu-emacs@gnu.org; Mon, 06 Jul 2020 23:02: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, 07 Jul 2020 03:02: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.15940908927018 (code B ref 41531); Tue, 07 Jul 2020 03:02:01 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 03:01:32 +0000 Original-Received: from localhost ([127.0.0.1]:35232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jsdrP-0001p7-Kn for submit@debbugs.gnu.org; Mon, 06 Jul 2020 23:01:32 -0400 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:46303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jsdrM-0001ot-UD for 41531@debbugs.gnu.org; Mon, 06 Jul 2020 23:01:30 -0400 Original-Received: by mail-wr1-f52.google.com with SMTP id r12so43470406wrj.13 for <41531@debbugs.gnu.org>; Mon, 06 Jul 2020 20:01:28 -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=/4/eMZe+wU9ly30PODQJyvOmz89mN/3C5BM16El2qzY=; b=aW7I+d+obJvoQURp+OYT6eDOIl8nJnWIO7ph9apJQudj9kSqB67NfSgWP3RHZ8Sc9s XQQKVKE6jNS7k5RM/jSEr5qxC5Hb2l7ZzPqG/kIo0htITIOp01r68l3VF8E7rL+dnU8t PMwwQgFGyX67kG/TRBBmGt03UCoWXjz+Xl7dV4Jmzuq9Xev6PVESX+AZrr79eLRe+Z5c RQPUxX6YlDiBnRwzqWIOchwIU5nKOZx0S5zaIG9wec0h6qyEIv4UxxLrEIohimdxuBfV uXE0dp8juTe6Ej5o2ODHAlwzuWRsqOmzTRpyo7Y281kMBVcSJWeU4pcdHeQyGS58hHiE GwxA== 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=/4/eMZe+wU9ly30PODQJyvOmz89mN/3C5BM16El2qzY=; b=pHmCwnRIWykar5fSKs2DH6q57HXq57WmbMx4wBOi2J8BNBPJOkcWdB1xFR6v+ibu4F /DhZDuoJGcDk7LJFq4Csj47+4A/WGU3boN2RA2dbJ35zP/kpf9jznYDEUlg0qAlCD0n+ 5qxcbP3cJkmMUNNmLrWUViD3yVRq4mJB0gVFGLmc64DUHqjxWyLFno8aO5t7gTDfcmVz Xrxrj9G4mqrH1v68SQXy1ahYEEnAr6WVSdFTk1DF+Q+7vP1KACknN2Zc4fJHbeIMvP3I LBjci+WHtNRDP3Di2vnKBZ6FWpfkSHqs5KViueBA+7H9DYFWmEzOkeJzQ8iQ5MAb2DMw elgg== X-Gm-Message-State: AOAM5309OD+0cllJ4lby/tCr94Dr7wHeN1lyjb6Vzt5Hxur2WHPvNnCj ow+z3Pm9ZadTU1RNnY+rj84= X-Google-Smtp-Source: ABdhPJwDVflGGmUrSOE9SFV8BSWZiN0M6/Az5u6KdNF5YPkZlEEer8rXIPGN751wy3MvR4xlkjeEqg== X-Received: by 2002:a5d:484b:: with SMTP id n11mr49491876wrs.320.1594090882869; Mon, 06 Jul 2020 20:01:22 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id e17sm25716592wrr.88.2020.07.06.20.01.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 20:01:21 -0700 (PDT) In-Reply-To: <87h7umop62.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:182775 Archived-At: On 05.07.2020 02:07, João Távora wrote: > Dmitry Gutov writes: > >> [that is the] "transition" I meant here. >> >> If you have other questions, please ask. I meant questions about futures as pertaining to eldoc, of course. I have other uses in mind, but redoing existing features is a less urgent endeavor. E.g., Flymake is stable, and I don't have any particular bugs in mind that need solving. So I'd be fine with keeping it as is. Unless someone wanted to take advantage of extra features that futures provide. > If it wasn't clear, my suggestion is that you send your earlier > dimtry-futures.el (as I am temporarily dubbing it, for clarity) to > emacs-devel, along with a rationale for why it is needed and where it > can be useful, not only in eldoc.el but in other places in Emacs that > use callbacks like like url.el, flymake.el, jsonrpc.rl, timers, > completion, processes, etc. You may want to include a short comparison > to Christopher Wellon's aio.el, if you have studied it. Yes, will do. But note that when I argue for futures, it's for basically any implementation that has a container for such values, and a set of common functions for manipulating them. Christopher's version would serve that just fine (with copyright assignment signed). Which exact version to choose, however, can indeed be discussed separately. >> I think I have described at length the very simple idea of what it is >> supposed to improve: provide a standard primitive and a library of >> composition/manipulation functions that would make these operations >> simpler. Which can be used in Emacs core, and in clients of the >> various facilities and expose future-based interfaces. > > Maybe I missed something, but I don't consider our discussion an > at-length discussion. It also wasn't a discussion really. Too one-sided. >> You seem to be in a hurry to get this in for some reason, but I'm fine >> with waiting a little more, if we get a better result. > > I want to fix longstanding problems in Eglot. I have limited resources, > mainly time. It is you who seem intent on not letting this go in, as if > you won't be able to prove that "better result" after it does. This is > absurd: if you do show it to be better, then we should migrate eldoc.el > etc to futures. ...as I've said a trillion times already at this point. 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 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41531#8, and then went on with your own vision of of "simple" function based async, full on with extra features and additional incompatible API changes. >> Please recall how you rejected my proposal along the same lines. > > I don't remember your proposal fixing anything in eldoc.el, you merely > suggested I experimented with a technique. Which I actually did, and I > didn't see any advantage in it. It certainly did away with clients having to call eldoc-message. And if shorter code and better backward compatibility are not advantages, we might disagree hard on the meaning of the word. >> But the problem you seem to be urgent to fix (having eldoc-message >> called from client code) is not so terrible that we can't wait until >> the future-related discussion at least has had a chance to happen. > > I've explained repeatedly: this is holding up multiple things in Eglot. > I want Eglot to serve diagnostic messages, and various kinds of > automatically gathered information about the "things at point" all > through eldoc.el. Then move on to better stuff, of which there is a lot > in LSP, as you well know. Also, this fixes SLY and SLIME too, both > hacking their way through eldoc.el. Possibly the same for CIDER and > other such extensions. This also opens up eldoc.el in non-async > situations as well, such as elisp-mode.el. Just read the patch. Aside: given that this discussion has user interface in mind, it needs more consideration of actual user experiences we'd want to allow. Ones 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. > But very well then, let's > have those non-futures objections in this bug report, the sooner the > better. To be sure, they will also contain the "how we could do this better" kind of arguments. Let's start with the basics: The new API is incompatible with the previous one, it requires changing a lot of functions (though admittedly in a minor way). Which is easy to miss, as evidenced by describe-char-eldoc which still doesn't accept any arguments. 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). 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? 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. 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, 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. 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. - eldoc-documentation-compose: Okay, this is kinda interesting (though not essential), and the implementation is not working as well as I'd hoped it would. It makes the echo area blink up and down as I move the cursor around. There's no expected truncation of individual docstrings when they don't fit in the window's width. And I don't understand what you expect it to do if several docstrings are multiline, and as an aggregate they don't fit the target height. I think the only reasonably predictable behavior would be to truncate each of them to one line, always. - eldoc-documentation-compose-eagerly: Ooh, now I think I see why documentation functions have to return these non-nil, non-string values. Is it that this particular strategy wouldn't have to wait too long for documentation functions that never intended to call back? Returning futures instead (when async is needed) would provide this kind of guarantee without the seeming duplication of signals. On a related note, I believe some facilities might want to use only certain "kinds" of documentation functions (as indicated by the plist arguments). If the plist is only provided together with the response, there is no way to avoid unnecessary computations (e.g. making HTTP 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). And in a different high-level argument: you stated that you intend to have Eglot use a non-default value of eldoc-documentation-strategy. Which would basically have you use Eldoc as a library, controlling both the list of documentation functions and how they are composed. Whereas having the eldoc-documentation-strategy defcustom at all makes it seem like the user's choice, and that all Eldoc clients must be able to perform well under any strategy chosen by the user. We might want to think twice before introducing such responsibility. 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 showed, or any potential "proper" ones would make backtraces hard to read and debug, and then introduced this kind of control flow with callbacks calling dynamically generated callbacks, retrieved from a variable dynamically set in a caller function up the stack (to be clear: I think having eldoc--make-callback variable at all is a bad 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. 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. 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.