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 02:35:36 +0300 Message-ID: <919188b1-154a-668a-7b0a-82fb96121c9e@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> <31721651-6c51-8c34-22cf-f68c0269016a@yandex.ru> 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="1199"; 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 , Andrii Kolomoiets 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 Thu May 28 01:36:11 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 1je5ak-00008w-WA for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 May 2020 01:36:11 +0200 Original-Received: from localhost ([::1]:51474 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1je5aj-0002PN-P3 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 May 2020 19:36:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1je5ac-0002Ox-MO for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 19:36:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38770) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1je5ac-0003pa-DN for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 19:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1je5ac-000751-AA for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 19:36: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 23:36: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.159062254627188 (code B ref 41531); Wed, 27 May 2020 23:36:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 27 May 2020 23:35:46 +0000 Original-Received: from localhost ([127.0.0.1]:50316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je5aL-00074R-Js for submit@debbugs.gnu.org; Wed, 27 May 2020 19:35:46 -0400 Original-Received: from mail-wm1-f46.google.com ([209.85.128.46]:50362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je5aK-00074F-An for 41531@debbugs.gnu.org; Wed, 27 May 2020 19:35:45 -0400 Original-Received: by mail-wm1-f46.google.com with SMTP id v19so1361443wmj.0 for <41531@debbugs.gnu.org>; Wed, 27 May 2020 16:35:44 -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=R5S9j4wWBT0hiIP+jN0OM7D04Jr1lwwSHN/mgxgqvUo=; b=j2OkaFNijkVVdjev9FzMqMb7hs2ZVfbJg/h7fRjcj9JqTOikJFtmhJ3uXMELQu+7fH siw26Pc3qp2rhxgOtgmFI75yF+sDN2VQ1ceJjv9Nsj2UgMd63j8eHTNNVoDMfP5Se7hO h0/cJS9+zSafVLZJFtV+5IrhZImQp9VqBLPfqUuSRxCaR/9Pm5St6QSqpPGoRfV2aG24 Cdfclq3hBXaBDnyNRn9jveTvO/sZF4WLiVjeKfGWvorBE6iHjnzhWWpS3xxKy1agOCFk rA8lK585xC6yTYBvVCbj3ikv0XUM6UVkr3eU8TVS+f+1ulZHrEMgE8+8fgIvTWMsKoZi iN5A== 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=R5S9j4wWBT0hiIP+jN0OM7D04Jr1lwwSHN/mgxgqvUo=; b=JGW9ZbFxth6VqTpgvh/6+d6z/cDZy6dVbM5y/7uHcowBcZgIZwClBrg3AKd71njUIP 7c4ZhVg80q6aaY3fOSG0Ab6/cxQGoPrLp9qHGWBLpOU8k2jmFDOtHXtL/0eFa5/QVNjl ynCeA0bkHfoyNOZ4mxnNab34nwBPKkFvop+zIYoOEPrePeBvmPMo642QOWLbvUcMqF6t hVJeYJ7M2gpgoHTIeE8crl8MAC9xjGRhJIq7UZJqT37rOcwfjbbKzBBMEb9ExAL1+9tM BiVErC5oiQn0XIRd7HkcDPwMGupckRhDYF9JUWvo8u2hqxj6snyrOBgkhsVgfdVKnWku 9qsQ== X-Gm-Message-State: AOAM531TRzEeuCyPp/4dc3yNuRHf7d+vyIyJ6sUeJBuLCV67M7P5l5m9 VG6FqaerBO42XjG30jXVvYM= X-Google-Smtp-Source: ABdhPJxPRxdVJxWlHIciIgUWgLqss+UhywQG7ESVaTIpfcmfTylhWNg35q2oHsG3wpb+oA73CCQpLg== X-Received: by 2002:a1c:1983:: with SMTP id 125mr462202wmz.43.1590622538223; Wed, 27 May 2020 16:35:38 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id s2sm4017811wmh.11.2020.05.27.16.35.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 16:35:37 -0700 (PDT) In-Reply-To: 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:181117 Archived-At: On 28.05.2020 01:13, João Távora wrote: > On Wed, May 27, 2020 at 10:14 PM Dmitry Gutov wrote: >>> 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? > > In the idle timer function. That's when it decides it wants > new info, and so any old info that hasn't arrived yet is probably > out of date. Then eldoc might shows some info when it's no longer pertaining to the context around the point. > But I think I understnad what you mean pre-command-hook. > You suggested pre-command-hook because that's where you > can check if point is far enough away from the place where > the original request originated? Or always abort, as soon as the user invokes the next command. >>> 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. > > That is a very confusing statement. It's a somewhat incorrect behavior that is, however, easier to implement. Which is fully along the lines of Richard P. Gabriel's "The Rise of Worse Is Better". >> 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. > > They need to _receive_ an object produced externally, somhow. > If they return a function as youv suggest, they are only doing so > they can later _receive_ another object. This is needlessly > complicated. To receive objects in some place, just use argument > the argument list of that place. "Returning a value" is meaningful semantic. Even when that value is a function. >> 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. > > No, it does make sense. Read it again. What you're saying is what I > meant. Perhaps you could have agreed then. > But that still means that the process sentinel will have to deal > with out-of-band kills that it must distinguish from other out-of-band > kills (such as, say, a kill -9 from the shell). That is added complexity. It's their choice. Some processes might run too long in certain cases. So that would be a safeguard. > It is better, in my opinion, to make this softer. Let the creditor > signal, I don't need this anymore, and the issuer will take appropriate > measures synchronously, i.e. in the process filter and not in the > process sentinel. Either way, that would require an additional way to signal. Try to fit this into your proposal. It won't match so well. >> That's the main idea behind aborting futures. Or canceling. Whatever >> term we're going to pick. > > But, again, nothing you're describing here can't be implemented > with passing a callback in the arglist. It's independent. Futures > particularly the versions you and Stefan are proposing are just > other places to type basically the same sexps. They're a stylistic > change over callbacks, but nothing more, fundamentally. Hence my request to wait a little. Stefan suggested the simplest version because it both fits your current requirements, and it can be extended without breaking that usage. >> Perhaps. I'm also not buying the usefulness of eldoc-documentation-compose. > > Yeah,I don't get it particularly, either. I mean, I can see its uses. > but I'm glad you're finally getting the overengineered feeling :-) No "finally", that was my opinion of it from the outset. > And it's waay more useful than futures here. Way to extend the bridge and then kick it down. >> 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. > > Code is read much, much more than is is written. And WTF per minute > _are_ a measure of code quality. I would like to avoid this particular > WTF please. Okay, here's another argument: "Promise", or a "Future", or "Deferred" or whatever, are common notions across many programming languages now. When a programmer encounters an idea familiar to them, they understand a program more easily. No WTFs. >> In any case, you are over-exaggerating. This exact design has been a > > "over-exaggerating". Very meta. Plain English. >> And not once have I seen a complaint that it's overly complex. > > Anyway, count one now. Or don't. I mean, I really dislike > company-backends throughout, but I don't use it, either. Noted. > I mean > I know you inherited it and I had to hack on it to add flex support > for the capf thing, but it's a strange re-implementation of functions > to have one single function that does wildly different things based > on one argument. I guess at the time there weren't generic > functions. And the cons :async thing is equally confusing to me. > Sorry to be frank. But I guess some people will love it, for some > equally legitimate reason: it will seem "right" to them, or "clever". It's very simple. Much simpler than generic functions or c-a-p-f. So I'm surprised to see you disparage both ideas (one simpler than what you do, another a tiny bit more complex) as complex and outlandish. >> Didn't you say that Flymake could use futures as well? > > It could, sure, especially if you have a thousand futuristic devs > itching to write backends but not grokking callbacks. But let's > not kill the existing API, please. Probably not. Unless we find a good use in it for the extra capabilities provided by futures. > Suspend this discussion? Sure, this discussion yes, if your want. > But not this bugfix: that would be exactly what "holding hostage" > means. Don't hold this bugfix hostage: it has nothing to do with > futures. It's a new feature, not a bugfix.