From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends Date: Tue, 26 May 2020 21:00:47 +0100 Message-ID: <87tv02pits.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="41925"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: 41531@debbugs.gnu.org, Stefan Monnier , andreyk.mad@gmail.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 26 22:01:15 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 1jdflD-000AoR-2z for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 22:01:15 +0200 Original-Received: from localhost ([::1]:37696 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdflB-0000At-UN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 16:01:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdfl0-00007Y-NY for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 16:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34853) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdfl0-0006hw-Da for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 16:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdfl0-0003RK-B5 for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 16:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 May 2020 20:01: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.159052325713204 (code B ref 41531); Tue, 26 May 2020 20:01:02 +0000 Original-Received: (at 41531) by debbugs.gnu.org; 26 May 2020 20:00:57 +0000 Original-Received: from localhost ([127.0.0.1]:46399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdfku-0003Qu-Sm for submit@debbugs.gnu.org; Tue, 26 May 2020 16:00:57 -0400 Original-Received: from mail-wm1-f41.google.com ([209.85.128.41]:40678) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdfkt-0003Qh-GK for 41531@debbugs.gnu.org; Tue, 26 May 2020 16:00:56 -0400 Original-Received: by mail-wm1-f41.google.com with SMTP id r15so817199wmh.5 for <41531@debbugs.gnu.org>; Tue, 26 May 2020 13:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=65wzmJ4kjjeU7kCUFUtgkrtM8NVFnj72JMijcRB8Zf8=; b=kCsZ8DIMZFAgJY8V2IaQPFREYAEdn+IhPBlTi7/hqVuJnKXumJELc2oh8JHJtzifrN n6kWzT5tdrgNJyUutv9wipkBFBzR8gGx77uPFIhTvJ6QFpIs3R9moewemGIsrBpm9Fyt 9s1Ry8896UFMXmIocciUfv4okrtG8d22uJ7AzW2CuWYpOj5zxAgwOV5+qpQt1fMsrDRM mCmi/AJZf7hq67IR8EdxZuFrevpL8usWDgljNRywElss789ncJ+tk9+Kkuf8ib7X8BQ3 gOlmZ7P+yFMPlKhFfKGI4irlbB9cGxT/R/C1B1fzsDHU/fE5L0YUwJnLe0+mVxYlgL9V aLjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=65wzmJ4kjjeU7kCUFUtgkrtM8NVFnj72JMijcRB8Zf8=; b=YHZMnulDNkWYnOy08a4PJjwo6fuGOknm/SB4yJQuN1+c58FNmAjTVfdJPfIP5bp3Ho DAkvsbexc7HJAda8qQppnn5A2yO7j9U1R9j4GvnSfa1DrTpk49wubvLJWZj5qnIlyeuN 0TbNIPdKhtmjXDGtJB6hul/XuSyOmunv70+9kC1fvk67Jx9dSW3w2x2gz9h06nlIrMZg t96vHaiBCVCc6pkWdpImzTSnuKX2B3iQR0Sjuz2zSl0M/Xocqa4wTEbt/gDUDDxKvNcN D0GkNf1Mc2WMr0EAVDsHA49ntL+HMh+8zKot+yRey0y8MjAnknQGCxEyd3cniZZ7Bg5w xCVA== X-Gm-Message-State: AOAM531sO/x2uOt5q5zYH+o0SLtfQOef4wio/XDQF7yySTE7DKMwrZ+l g//y9bmwUC+YJ4nsmpNNJD8= X-Google-Smtp-Source: ABdhPJwYed0lXewX0Cse12zQ+mK6KP+Wc6FPf84Q7bZATDnSk+Hy5wNzxiMDvExcQflSNRknT18DPA== X-Received: by 2002:a1c:7c0e:: with SMTP id x14mr751698wmc.1.1590523249276; Tue, 26 May 2020 13:00:49 -0700 (PDT) Original-Received: from krug (89-180-149-243.net.novis.pt. [89.180.149.243]) by smtp.gmail.com with ESMTPSA id z132sm598398wmc.29.2020.05.26.13.00.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2020 13:00:48 -0700 (PDT) In-Reply-To: <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@yandex.ru> (Dmitry Gutov's message of "Tue, 26 May 2020 22:14:31 +0300") 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:181068 Archived-At: 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. Invalidation may or may not entail letting the holder of the callback know that the previous call became invalid. 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. > 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. >>>> 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. >> is a bad idea. An abort switch whose contract is "just letting you know >> I don't need this anymore" is better. But again, in eldoc, not so >> useful. And again, nothing to do with futures here. > > Here as well. OK. The takeaway is that "aborting a future" doesn't need any constructs specific to futures, is all. > 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. >> +;; NOTE: The xref API is still experimental and can change in >> major, >> +;; backward-incompatible ways. Everyone is encouraged to try it, a= nd >> +;; report to us any problems or use cases we hadn't anticiated, by >> +;; sending an email to emacs-devel, or `M-x report-emacs-bug'. >> That has been sitting there for almost three Emacs major versions >> (in >> fact you added it after the initial 25 release). All I'm asking is for >> a little such flexibility with eldoc. > > I wrote that for xref.el because that was the state of affairs, and > xref was relatively new. Especially compared to eldoc. This part of eldoc.el is probably newer than xref.el was when you wrote that. > But we're probably miscommunicating here as well. Doubt it. > 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. >> 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. 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... 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". Jo=C3=A3o