From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer Date: Sat, 30 Nov 2024 10:40:05 +0100 Message-ID: <8734j9ukju.fsf@daniel-mendler.de> References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> Reply-To: Daniel Mendler Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18058"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 30 10:43:25 2024 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 1tHK0a-0004ZE-TX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Nov 2024 10:43:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHK0J-0006TO-2v; Sat, 30 Nov 2024 04:43:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHK0F-0006T2-3z for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 04:43:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tHK0E-0002iN-RB for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 04:43:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=IIv+xuvkGSw/+KlXf4+5BXZ+w3dIT4Pct2+AotKyPP4=; b=kttxg9vdy48YW/vOXoViyBczAQPv3KBDGd38ta94Taj1Rihcm3EO40s+/LG9MkMFAAEhiL27DUd78w5n4gUb9XiGsuqx4FS780DblV9c4fPQuE19cSbMCSC3P8lkvBXDP4cSh4DgDUvSZBLeHNNPgly72njZwaoMCArKhmtgtDZowz22I+YpbhtJgqZiB4cB/MZAsWITfhnxhHxYxotIKRnRBImmQecyNAex2yW4oOQ8AHAH1FjfOSiyJ1rTrWOA5xM6SXH790Mu+LfD9AiytHlOAD15sBhaUOuAueSQ+35neoEcmkqxDI34g0sy93FwyRD9shVt1LO6QpEHbB29ug==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tHK0E-00065g-7l for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 04:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Nov 2024 09:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74617 X-GNU-PR-Package: emacs Original-Received: via spool by 74617-submit@debbugs.gnu.org id=B74617.173295974723335 (code B ref 74617); Sat, 30 Nov 2024 09:43:02 +0000 Original-Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 09:42:27 +0000 Original-Received: from localhost ([127.0.0.1]:45423 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHJzf-00064H-By for submit@debbugs.gnu.org; Sat, 30 Nov 2024 04:42:27 -0500 Original-Received: from server.qxqx.de ([49.12.34.165]:54069 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHJzd-00063w-BF for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 04:42:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding: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=IIv+xuvkGSw/+KlXf4+5BXZ+w3dIT4Pct2+AotKyPP4=; b=omUBPjhNdjirTzie2fTKGcoapP CW2ixDT911kX/S7idzRE8PfLpWNqeR4kRs05esloGY5zadzlBXGa1S1VX2dUrMSS/w51OkY7Iyw7i H5dgU9JJwNxF987hs5zmyV/AGK0IryjPhhA2bxSa+dkjzG6L3ln2vYvWqawAMSSaHyQc=; In-Reply-To: <86frn99iky.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Nov 2024 11:28:13 +0200") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296122 Archived-At: Eli Zaretskii writes: >> From: Daniel Mendler >> Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca >> Date: Sat, 30 Nov 2024 09:34:11 +0100 >> >> Eli Zaretskii writes: >> >> > emacs -Q >> > M-x icomplete-mode RET >> > C-x C-f nt/INSTALL.W64 RET >> > M-x ffap-menu RET >> > >> > I see only the *Completions* buffer, no other display of the >> > candidates. What did I miss? >> >> Oh, right. I missed that. I think the problem here is that Icomplete >> uses a delay (`icomplete-compute-delay'). Other completion UIs don't >> have such a delay and show the candidates immediately. This makes the >> problem a little more difficult, in particular with respect to auto >> detection. > > Alternatively, we could consider the cases where more than one > completion list is shown a bug in the mode which shows the completions > even though the application already did. IOW, instead of considering > this a problem of the command the user invokes, consider this a bug in > the non-default completion UI currently in effect. It is basically a > flaw in the design of those completion UIs. I see it differently. The problem is in the tmm and ffap commands which lead to a mixture of completion UIs. Even if another completion UI is in effect, the default completion UI is called by tmm and ffap, bypassing the `completing-read' abstraction. It is not the responsibility of alternative completion UIs to work around this. Mixing multiple completion UIs is not ideal since it will lead to an incoherent UI and also to conflicts in how the user interacts with the minibuffer. >> Another alternative to auto detection could be that the completion table >> communicates to `completing-read' via metadata that immediate candidate >> display is desired. The completion UI could then act accordingly. >> Default completion would call `minibuffer-completion-help' and Icomplete >> could update immediately, ignoring `icomplete-compute-delay'. > > This sounds too indirect to me, it could cause unintended adverse > consequences, especially in nested scenarios. By using the completion metadata as part of the completion table, the effect on nested scenarios is explicitly avoided. Problems with nesting only occur if a variable is let-bound around `completing-read'. > There's a simpler alternative: we could say we don't care, as long as > only a few alternative UIs have this issue. It isn't a catastrophe. I care. But I do agree with you that the issues are minor and far from a catastrophe. The pattern where completion commands want to display candidates immediately is not uncommon. There are ffap, tmm and multiple third-party packages which have such a requirement. So I suggest to not necessarily treat "immediate candidate display" as a bug report, but rather as a feature request for `completing-read'.