From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: Improvement proposals for `completing-read' Date: Mon, 12 Apr 2021 02:40:30 +0200 Message-ID: <8117fc58-4dae-d0b4-43d8-d2e521d1e586@daniel-mendler.de> References: <09b67fc5-f8fd-c48a-8b0b-ad47c88761f1@yandex.ru> <292a9f63-5a41-7b32-66f2-67d06f138a09@yandex.ru> <7d03e917-6a61-23b3-e735-a8e43c3fb65f@daniel-mendler.de> <01ffe85f-6bdb-39a5-b20a-e3c60bea3e2e@yandex.ru> <759ed5ae-8d58-e73b-244b-08bd86aafb2d@yandex.ru> <000385dc-a234-ade9-584b-c4f515d7b01f@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29710"; mail-complaints-to="usenet@ciao.gmane.io" To: Dmitry Gutov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 12 02:41:31 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lVkdv-0007dP-2h for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Apr 2021 02:41:31 +0200 Original-Received: from localhost ([::1]:58156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVkds-0002o6-MX for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Apr 2021 20:41:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38156) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVkd3-0002Cr-Ka for emacs-devel@gnu.org; Sun, 11 Apr 2021 20:40:37 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:34499 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVkd1-0002l7-6T for emacs-devel@gnu.org; Sun, 11 Apr 2021 20:40:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OLxLKAHbFM4ARdUWUdS1eO371vCBslfVP6duSBk+mXs=; b=YfUfhd7pwNTmJbeC5EwSWjU2qc jor3oZuzY/bkGi8dTtOaGD38zD7bHWDlYY40+GGboGhdXmaU52NtJWqXr2XK8vPTSv+KfsN/JwLnk ircxV8zR79MDciZ5cSJNos7D03PvvZvXn72W93JU0KK+5N2jSJyqXj1CcMgJWD2Wprc8=; In-Reply-To: <000385dc-a234-ade9-584b-c4f515d7b01f@yandex.ru> Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267937 Archived-At: On 4/12/21 2:32 AM, Dmitry Gutov wrote: > I'm not sure if that would work for code completion. Aside from tracking > which value belongs to which frontend, and the associated bugs with > hooks you mentioned, how to you invalidate the results? > > For instance, there is a request, it has been made a while ago, and the > context has changed (the buffer has changed, position has changed, etc). > The request has taken a long time but finally the response has arrived. > How do you reliably ignore it? Or, ideally, are able abort it (if it's a > one-time external process, perhaps killing the search process)? > > If the result is some kind of "future" value, the handler code can > either change some variable in the lexical scope once its execution > reaches the point of "we don't need that computation anymore", or could > even call some generic method like future-abort. > > How does the general refresh hook solve these problems? I don't know how it looks in the context of code completion. But in the context of the minibuffer completion, the state is minibuffer-local. The hook is executed within the minibuffer, which belongs to the async operation. With Consult async you can have multiple recursive minibuffers where each performs an async operation. Does this answer your question? Daniel