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 16:57:13 +0300 Message-ID: <384e543b-61fd-fe10-605c-b511499ecec2@yandex.ru> References: <875zckuet9.fsf@gmail.com> <4987863b-d390-5f87-eb1c-2cca4f4b7262@yandex.ru> <87k10zsd85.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="60229"; 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 15:58:09 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 1jda5p-000FXF-Jf for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 15:58:09 +0200 Original-Received: from localhost ([::1]:58528 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jda5o-00061j-Ks for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 09:58:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35754) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jda5i-00061Q-Ln for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 09:58:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34468) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jda5i-0003NI-CV for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 09:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jda5i-00018j-Br for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 09:58:02 -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 13:58: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.15905014444333 (code B ref 41531); Tue, 26 May 2020 13:58:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 26 May 2020 13:57:24 +0000 Original-Received: from localhost ([127.0.0.1]:46014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jda55-00017p-FU for submit@debbugs.gnu.org; Tue, 26 May 2020 09:57:23 -0400 Original-Received: from mail-wr1-f42.google.com ([209.85.221.42]:37588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jda53-00017a-98 for 41531@debbugs.gnu.org; Tue, 26 May 2020 09:57:22 -0400 Original-Received: by mail-wr1-f42.google.com with SMTP id x13so5845015wrv.4 for <41531@debbugs.gnu.org>; Tue, 26 May 2020 06:57:21 -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=EybqiaDOwRdFbRmxeL7fOULWe099yWtPh4HpMgOSU5s=; b=Jv/7hSkBiji4dtzzBpsFfglD+CE9nLg36c8rbvZurcVHSvJ/Ff7NdnAkcU/dae5Zy8 jkYOhlpHbuenwK5Mp7C+/Y3Xoj7/dhrH/q8q4PzKQ617tI9wsYEY9m4CgytZCjTzJ7SO 93LDj6d0ZT3BVc75TuheH+gA0RPm6Mu/DXB9/H0CRC5piitfsl1Ym//moZNOWSzB1r2j eefGK88+hjqp++87fuNOoCkcfaGQadFVTiwqW/Bvl8oEeQBGP0qaWME707F7gdfUWQ45 J6MRJNMTn5q1AkB8DQTsPJbtMwNBKjkYX2fCm+V9QD41424smvU7pENB4xoLBGPZtzrf FCsQ== 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=EybqiaDOwRdFbRmxeL7fOULWe099yWtPh4HpMgOSU5s=; b=N8U7zz8gxXvZ1FwRuRsg9NB5Mipk8Y5VoZOq3+jPV8Xk3RdLXwqdaU3LZJEsKsWjDY 3BS+nWRRWlclGSin/ala9bEAlHU0Pqivqon2kzr9yOQUny66lFsIXWeQjJ8HgzRJfCr9 4bXwO3JCFrizerqKxZ+F8adjW804zl/rpqFELLjLR7YCy5zXwRK03SXxxxsdj7xDHikF 2+NE7EwIwB0E0ErWm76xo15LprWPJzOY5NnkEo4BejMj9fMKz7pYYy9deTpMqD+CUZcT oXB34cEA8Xv6/ZpP8fQgS0pyh/WAdEVKwb2lLGO/MVvRV2kcISV4NknC0lSef/uhh7oj oYsQ== X-Gm-Message-State: AOAM53012N/1OLkz+e2vAC3cEzMxK6/qgZmfMS/q3YjVTVGVS5Ei73+J itFjafl0iSEj1pnMX2Hn520= X-Google-Smtp-Source: ABdhPJxhtJ1qsbGvCEuos2NEsO/bHWQOzPNs0rpPF9EUEoQ7KvniqrzaVFm9iUTt6RrprvSU9Cadbg== X-Received: by 2002:a05:6000:11ca:: with SMTP id i10mr20825580wrx.10.1590501435159; Tue, 26 May 2020 06:57:15 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id o20sm9571670wra.29.2020.05.26.06.57.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 06:57:14 -0700 (PDT) In-Reply-To: <87k10zsd85.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:181033 Archived-At: On 26.05.2020 04:21, João Távora wrote: > Dmitry Gutov writes: > >> On 25.05.2020 20:04, João Távora wrote: >> (add-hook 'eldoc-documentation-functions >> #'test-eldoc-async 0 t) >> >> (defun test-eldoc-async () >> (cons :async >> (lambda (cb) >> (funcall cb "doc here!")))) > > Thanks. As I told you, it's not bad. These aren't exactly "futures" > though, they're a way to simulate argument passing. It's a simple stand-in, easy to replace. > I prefer my > version, which matches what flymake.el, url.el, jsonrpc.el, sly.el and > others do. 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. >> If you like, we could simplify the returned objects to be just FETCHER >> (as documented in the patch) rather than (:async . FETCHER). But the >> latter seems more explicit. > > Yes, if we do go with your version, I'd like that. The latter is hard > to read and understand from the docstring. I think it's more explicit, and once you understand it, it clicks. But that choice is not important to me. > 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. >> There also exist a possible modification of this patch with a bit of >> functional programming where both calls to eldoc--handle-multiline >> happen from inside of eldoc-documentation-default's definition. > > Yes, that's independent of the shape of the callback we want to use. > 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. 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). > 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? >> 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. >> 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. > 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. > 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. > 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. > 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?