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: Sun, 5 Jul 2020 00:27:20 +0300 Message-ID: <5d768a69-3574-10c5-e80a-8ab77ec60462@yandex.ru> References: <875zckuet9.fsf@gmail.com> <87sgecssch.fsf@gmail.com> <87tuynsdp6.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="26393"; 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 Sat Jul 04 23:28: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 1jrphl-0006kW-7y for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jul 2020 23:28:13 +0200 Original-Received: from localhost ([::1]:47996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrphk-0000At-83 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jul 2020 17:28:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jrphb-0000Aa-Cy for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 17:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48213) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jrpha-0003Bm-As for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 17:28:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jrpha-0000XE-5r for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 17:28: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: Sat, 04 Jul 2020 21:28: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.15938980502015 (code B ref 41531); Sat, 04 Jul 2020 21:28:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 21:27:30 +0000 Original-Received: from localhost ([127.0.0.1]:59759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrph4-0000WR-1y for submit@debbugs.gnu.org; Sat, 04 Jul 2020 17:27:30 -0400 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:46861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrph2-0000WF-SO for 41531@debbugs.gnu.org; Sat, 04 Jul 2020 17:27:29 -0400 Original-Received: by mail-wr1-f46.google.com with SMTP id r12so36457683wrj.13 for <41531@debbugs.gnu.org>; Sat, 04 Jul 2020 14:27: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=8fGAzBO7qxQEvrHhytcXR47y8aU1Fqh8ePC6ZJC+9+M=; b=QwF4K5QtcK6qgG+Vd6iFWtZyXas4uhDS10NQGPEPvl/TubbRNapWdyZygi/Hiikgxy gR2j6H/oeT+J9E6qDSZzONW8JOxd44IwkmRMMk/Wi5mc/HoXqT2RQdY1jAzCKKj7OcAF kaGcr4QDwnjTstpSTXwc8Jax6WNPrMG8saKU/5FCZDF2kgTdtY/ZY52J8uOfRnbUdumd I271rDSFBWGAedF5vWmmf+uYqKNRNL5WsxAQETg+NHoN5Jj4CSK9TmG9+n4YysMk3NKV GdiIcSYK+70yUmzsYvzmTQJ6qhwtqh6uJJIXLOdpgFczQE+9MWbUW6MxmTTGo+GoviGI uaXA== 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=8fGAzBO7qxQEvrHhytcXR47y8aU1Fqh8ePC6ZJC+9+M=; b=pMdWyp5NCUT82UXZ4WGmNKYOw1Oy5HSQeOL34XfHYg2ZKgLbgvu+7JgHyFBJwFU0bR 3+Iiu0wSpOIiRGfU0WFIm9MIlBbm4vtwGEPVwQCJvGVXy8PW4CvGy6Zn1c9wskYYLj7x O07mL9JvW5OoQ6XUnBCyG35SPJ97UettZKo0tXtsA32DrTPsxPw+5J12DPaIx5uFGNVw sB7wF/jJOyE05QZeTXSZSlhfI60MtGhgT1eawGOENptks0+lbozGBU4rO0GYHD2AyF8g nCsdDSYJeX6cRZsfs4ZusftQAFdoXNE0zxqzsxzVNo5zCaEKKronTHUsQ/96Yk8acZ+r 5M6g== X-Gm-Message-State: AOAM5307XaAClbNK/C7JpD2lxQaXQyEInCMbfpPA/NlJE4N7uJFKkbrg /XLOzKtJe2bTmiljHIodKus= X-Google-Smtp-Source: ABdhPJw7lssnIMg52lV03lLvFUJ+P4OLvrhjsJu9PqQthjlfEUlhR+QX0dHv2h5u38rfapE3lPMoeA== X-Received: by 2002:adf:81c7:: with SMTP id 65mr40206857wra.47.1593898042900; Sat, 04 Jul 2020 14:27:22 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a15sm20882146wrh.54.2020.07.04.14.27.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Jul 2020 14:27:22 -0700 (PDT) In-Reply-To: <87tuynsdp6.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:182717 Archived-At: On 04.07.2020 14:48, João Távora wrote: >> Unsurprisingly, I object to this approach. We should have better async >> support in multiple Emacs facilities, and that means standardizing on >> some particular async primitives and functions that can manipulate >> them. There is no need to release support for ad-hoc async values (you >> didn't like mine, so it's only fair play that I object to yours) when >> we can transition to full futures right away. > > I haven't seen a consistent plan "for transitioning to futures". Do you want to see the patch based on your code? It's the only "transition" I meant here. If you have other questions, please ask. > All > I've seen is (complicated, IMO) ideas on how to avoid the > callback-calling style by hiding the callback in an object. Hiding is absolutely not the point. > I've seen > little argument or discussion of what futures are supposed to do or fix > or improve. 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. > And I've seen no feedback from the author of what seems to > be the most promising futures library, aio.el which uses the > generator.el library, to provide, presumably, more elegant > "language-level" futures (i.e. futures that aren't only hiding the > callback in some other object). I'm very curious to know Christopher's opinion myself. Based on my experience, this will result in a much longer, protracted discussion, if it will result in one at all. 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. > Despite that, I've stated here repeatedly, tiringly: In principle, I > don't object to futures at all. I just think it has to be a > thought-through change. Propose your library to emacs-devel and let's > iterate it there. If you think emacs-devel will bring more feedback, no problem. >> I'll get into a little more detail in the more full review, tonight or >> tomorrow, but for now my impression is that, in the absence of such >> standard library and async manipulation functions, you decided to >> implement them specially in Eldoc. > > Of course, and that's what engineering is about. For the most trivial > of changes X there is _always_ a refactoring R that will make > implementing X and a possible Y and Z much simpler, more elegant, more > "meta". Knowing where to stop is what this game is about. In this > case, there is only a vision what Y and Z might be, and a foggier vision > of how bad/good design decisions in R might affect them. The thing about refactoring, is it doesn't change observable behavior. Refactoring would keep the stable interface (and e.g. reuse future-based utility functions under the covers). Whereas the improvement I would like to see here, would change it. So it's not something that could be simply moved to backlog. And as I intent to explain later, I believe you will need future-manipulating functions inside eldoc client code anyway, for best user experience. So we might as well bite the bullet and introduce futures at the API level. > So I fixed the real, actual problem in Eldoc using the async paradigm > that is widely used in Emacs and most widely understood by programmers > of all (most?) trades: callbacks. Please recall how you rejected my proposal along the same lines. And it's fine. We can do better. > And, again, for the nth time, there is nothing in my code that prevents > your -- or someone else's -- "futures" library to be the nec plus ultra > of async in Emacs. But, in the meantime, I won't let you make these > Eldoc changes hostage to your predilection for futures. "won't let you" is not exactly how things work here. We usually try hard to reach a consensus. In any case, I have considered this for some time, and my arguments for "let's work on this some more" won't be limited to futures-vs-callbacks. > It's quite a > legitimate inclination, of course, it musn't be needlessly put it in the > way of other's work. I agree that there are improvements to be made in documentation-related code (whether it's in Eldoc, or not), and I also think that you might not be going far enough in some respects. 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.