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 13:04:33 +0200 Message-ID: <9c780787-e205-6344-4cf2-dd67b14db1d9@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> <8117fc58-4dae-d0b4-43d8-d2e521d1e586@daniel-mendler.de> 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="40344"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 12 13:05:50 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 1lVuO5-000ACx-N9 for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Apr 2021 13:05:49 +0200 Original-Received: from localhost ([::1]:53612 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVuO3-0005cg-1U for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Apr 2021 07:05:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41760) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVuN0-0005AB-2E for emacs-devel@gnu.org; Mon, 12 Apr 2021 07:04:42 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:34949 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 1lVuMw-0003C3-NS for emacs-devel@gnu.org; Mon, 12 Apr 2021 07:04:41 -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=LdhI8UqOmmv2wpbUFNMTUkhppC+J9fXZukAKX1ILi2o=; b=IbStMvmFLM7dBRJdj/S91aj3/I GDpM0jUEtoP+xzYNuYQGZgcw/gPSnrRF5ZI9u6TU0M2DkyRzhTVflG6hD0QqC0Y8VRPsjDlA6Prdp VSLISFpy3dSGWPD7hzivNifvDuwhu87hLsDxD1UhVrM2lz8vBbWUbiKF+bcgLQVZGwnk=; In-Reply-To: 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:267952 Archived-At: On 4/12/21 12:47 PM, Dmitry Gutov wrote: > What happens if you have an anomalously long running request in one > nested minibuffer, which you exit, so it arrives in the "parent" one > that's still managed by Consult, but shows the results for a different > command/input/etc? This cannot happen. If you exit the minibuffer, the running request will be terminated. The parent minibuffer, maybe also running a Consult command (or something else) is isolated from the child minibuffer and no disruption should happen. I just tested running nested `consult-ripgrep` and that should work, but for some reason there is a problem (https://github.com/minad/consult/issues/272). I have to check if this can be fixed. So what I described to you is how everything should work in theory, since the state is captured in the closures. The `consult--async-sink` contains this code which performs the refreshing: ;; Refresh the UI when the current minibuffer window belongs ;; to the current asynchronous completion session. (when-let (win (active-minibuffer-window)) (when (eq (window-buffer win) buffer) (with-selected-window win (run-hooks 'consult--completion-refresh-hook))))) Daniel