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: Thu, 28 May 2020 00:14:00 +0300 Message-ID: <31721651-6c51-8c34-22cf-f68c0269016a@yandex.ru> References: <875zckuet9.fsf@gmail.com> <4987863b-d390-5f87-eb1c-2cca4f4b7262@yandex.ru> <87k10zsd85.fsf@gmail.com> <384e543b-61fd-fe10-605c-b511499ecec2@yandex.ru> <87ftbmr8d9.fsf@gmail.com> <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@yandex.ru> <87tv02pits.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="68324"; 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 Wed May 27 23:15: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 1je3OK-000HfV-8G for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 May 2020 23:15:12 +0200 Original-Received: from localhost ([::1]:52384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1je3OJ-0006GC-40 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 May 2020 17:15:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1je3OB-0006Ff-80 for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 17:15:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38589) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1je3OA-0007ON-Ut for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 17:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1je3OA-0005an-Hy for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 17:15: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: Wed, 27 May 2020 21:15: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.159061405021403 (code B ref 41531); Wed, 27 May 2020 21:15:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 27 May 2020 21:14:10 +0000 Original-Received: from localhost ([127.0.0.1]:50132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je3NK-0005Z8-B8 for submit@debbugs.gnu.org; Wed, 27 May 2020 17:14:10 -0400 Original-Received: from mail-wm1-f45.google.com ([209.85.128.45]:39434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je3NI-0005Yu-G9 for 41531@debbugs.gnu.org; Wed, 27 May 2020 17:14:09 -0400 Original-Received: by mail-wm1-f45.google.com with SMTP id k26so995325wmi.4 for <41531@debbugs.gnu.org>; Wed, 27 May 2020 14:14:08 -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=ToU3oVOpgrnFc3ErbFYGXrSJMEfsfZtE5OOMHRZbsCA=; b=ZvDJRe8fD6O26Mhwi0llsBS1CIwvHNa2ti/QgdA2WsqyhB3lZmf0tlRbA2pTYxO8Fo nhEAh4DlbkTcT+JwlQJ3J07buAKHOjNYkYt9BptzNEFB5JHRqZmZYE+jQ/+XQ7Df7f18 /PSm7JuW7SPEvdmWbt2MgTUnt74NqjVS0KWppTBjTjm0IpBSzhhMmu5+M0Vbvv4R7fM/ J1UwaAT4yRNdPZyEX4msn54o4AIN5FUih8gEljWpr6kjT5J7JpyAFG6hG1KJRoNivu2V FFyPiLcCCxeH0r6LyUkb85Var6Xvnhomar65FEMF8bnE+sZBE7ZFZTuPQRF+BVEOI8p8 5opA== 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=ToU3oVOpgrnFc3ErbFYGXrSJMEfsfZtE5OOMHRZbsCA=; b=mXvQqPZxBF1YUSSTW2PJjjZF36yXhEeUYMHFs/TqS+mbvTBujkosibWRLB56Ti3l9P 5krqpyKRWv6S5E7myZYsIQ7hbisD+6NxapljXub0ho+EM1FVlv08ci6nw2s2i8xpcLgY rqPPCMrl0U7Gh0pgPZ+AO25OaN4/nsL/139OOFhEr2rbJNB5s4YE6ASBjzaGheC08x5q 5F9SFdAZQiyz++cMk31knon6jc/RrVdwYnne9fOT1+RbADcMyoXrjCwhIwACpNXp9bTJ cssVl7bkdzA07rPqE2iFz+UaydUCd2s0rGXXeS3pFZBkth60+CtGLX2OTPN4U2ClM2a+ n39Q== X-Gm-Message-State: AOAM531aWUuwhBXGkX7kdu202kpssgZFxW/7p5wYC3nU6L9KWr9Q99FG ttoHBhSB6BgovmzcYINpxFE= X-Google-Smtp-Source: ABdhPJydkmWNT4zstF310tG1jnryu3yOfMT8t+xsZwVg5rcp/n98dvlkPeirbokSs3GllSBDIkqAHA== X-Received: by 2002:a1c:de46:: with SMTP id v67mr62188wmg.146.1590614042414; Wed, 27 May 2020 14:14:02 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id d4sm3766517wre.22.2020.05.27.14.14.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 14:14:01 -0700 (PDT) In-Reply-To: <87tv02pits.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:181108 Archived-At: On 26.05.2020 23:00, João Távora wrote: > Dmitry Gutov writes: > >>> no idea of it. In the framework you either make the callback a noop, >>> or you set it aborted for the client to save some work. Or both. >> >> So the abort thing. In pre-command-hook? > > No, the creditor of the future or issuer of the callback aborts or > invalidates the previous version just before issuing a new one. Nothing > pre-command-hook here. Where/when would eldoc-mode do it? > Invalidation may or may not entail letting the > holder of the callback know that the previous call became invalid. Letting know the issuer of the future, you mean. > Flymake does this: by invoking a backend again with a new callback > instance it is signalling that the preceding one became invalid. If the > backend tries to call the previous callback, it is an error and the > backend is disabled. Worse is sometimes better, we know. >> It's good to have a well-documented contract. Functions do >> _everything_. They can't be optimal for everything. > > You're missing a Lisp point here. It doesn't matter if it's an CLOS > object, a struct, a function or my beautiful singing voice: it just has > to be an object which you can make unique instances of and can respond > to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf > errored-p). That's the contract. A function fits perfectly. That would be my "alternative" suggestion: for eldoc-documentation-functions elements to return a function (denoted as FETCHER in the docstring) if they want the async convention. >>>>> 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. >>> Not really, it asked a client to solve a problem, doesn't know how >>> the client if the client is doing by async process or cointoss. >> Seems like we're miscommunicating. > > Well you implied that the creditor of the future (the caller who > received) created the process. It does not. See the patch to Stefan. Okay, creditor != creator. But what you've said a few messages back (seen at the top of the quotes chain above) doesn't make sense: the creditor will call (future-abort fut), and the issuer of the future can make sure that this operation will indeed kill the process. That's the main idea behind aborting futures. Or canceling. Whatever term we're going to pick. >> See above about not having to change anything. > > But then we don't have to change anything in any case! I already > changed EVERY user of eldoc-documentation-functions: every single one of > the 5 in existence in the entire world. So we're all good. And then we'll need to change them back. And in the meantime, the new convention could get external users (some people do live on the bleeding edge), and this will get messier. >> OK, I see your point: eldoc-documentation-functions is new. And >> apparently you don't intend to add this feature to the variable >> without "s". > > Yes, exactly. eldoc-documentation-function should be obsoleted IMO. Perhaps. I'm also not buying the usefulness of eldoc-documentation-compose. >>> It just looks like you're holding this problem hostage to introducing >>> some kind of rushed futures solution. I don't agree with either of >>> these things. >> >> Who's holding what hostage? I showed a smoother approach, you didn't >> like it. No big surprise about that. > > Let me explain. First: it's clearly not "smoother", your're asking users > to wrap their heads around a function that returns a function taking a > function. That's not what I want to present to Eglot contributors, for > instance. Would they need to? As soon as an existing Eglot's implementation is in place, that exact part of the code wouldn't need to be touched often. In any case, you are over-exaggerating. This exact design has been a part of "asynchronous" backend calling convention in Company for years. And not once have I seen a complaint that it's overly complex. > And I'm not too crazy with presenting them this "future > thing" that is completely different from Eglot's use of Flymake, > jsonrpc.el, completion-at-point, etc... Didn't you say that Flymake could use futures as well? > In other words, my ambition is > consistency and you seem to be denying it for reasons I can't > understand, because nothing in the steps I am taking denies _your_ > ambitions, which seem to be futures. That's why I speak of "hostage". See above. But perhaps we should after all suspend this discussion until we had a chance to reach a better mutual understanding of the futures API, and how we expect it to help (or not). I promise to show some proposals in the near future.