From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer Date: Sat, 30 Nov 2024 10:19:34 +0200 Message-ID: <86ser99lrd.fsf@gnu.org> References: <87r06turur.fsf@daniel-mendler.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12959"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 30 09:20:23 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 1tHIiF-0003Dk-2f for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Nov 2024 09:20:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHIhw-0004qF-KX; Sat, 30 Nov 2024 03:20:04 -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 1tHIhv-0004oV-57 for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 03:20: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 1tHIhu-0008Cq-Sc for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 03:20:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=QWtFBun54f6eOaoBDtIibfJfmV6SnddXQZfRXzOSgO8=; b=Dp43639QSikZsOFJ84Jq4EaCod0D9XKbXT7IinzLf8cBn6MNAbXhYCcd8fjG0eo7+1dPO1ZrA+s48vR3k8liV1hxHRipm8lTYvhSekljCPR1of2hRdWrdX4i4H+LS7KAmtk2tYzWcwQkIp8MzfazQsfxubfaPgSP3zrV5pZ5RE1Fcu2vePz+du/q/3fLgp7UJ6AW+iMRYlR6mBnDmvsI09N0Dzzie5voQy9TUZVr/7tjQY8Q75QGorqV+0y7UqhI1B44mAIsNRpXzMwCsnE/zm4HIjPHaJ7h4vUhW1SFIZv3NiawYAWFvMm9DK3vUMXqEuZMYUNWTClvECKQPzKl3A==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tHIhu-0001pd-Md for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 03:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Nov 2024 08:20: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.17329547957013 (code B ref 74617); Sat, 30 Nov 2024 08:20:02 +0000 Original-Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 08:19:55 +0000 Original-Received: from localhost ([127.0.0.1]:45312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHIhn-0001p2-9V for submit@debbugs.gnu.org; Sat, 30 Nov 2024 03:19:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHIhk-0001om-NZ for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 03:19:53 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHIhV-00087G-Nn; Sat, 30 Nov 2024 03:19:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=QWtFBun54f6eOaoBDtIibfJfmV6SnddXQZfRXzOSgO8=; b=bYrEMld7iEHo cE2bTlCHtn/7Z694YYtFpGE0hZOE0dLe8NKqZoCarmpFaMLhtiOu0Nw+eqYyiWLKpVWB87NLFJnyl 1kFSKeZlR7F3jI1eYfYjI0PJvsR/ANz3TvsaP5pHF3lg2SVEyjRFEckCk8+1lhjoh70PdnBv92Ie0 uFYOiquQ7MrEasR7DLzGJi05DJ7TzhKqf23DvIdF7y4GUWTKZlmCFQUZYBhL3roLLYnzwP5XgbvZJ rQq95AdcbiR33VyTlrm0HZRYvbhmk8g2imdevBvhyf8HwE7UyEsRg5P5Fc5zJIrfEFaBAjiEu4w8S +nA0zzzPKOP77OyzvJDaSg==; In-Reply-To: <87r06turur.fsf@daniel-mendler.de> (bug-gnu-emacs@gnu.org) 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:296119 Archived-At: > Cc: Stefan Monnier > Date: Sat, 30 Nov 2024 08:02:20 +0100 > From: Daniel Mendler via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > `ffap-menu' automatically displays the *Completions* buffer by calling > `minibuffer-completion-help'. If an alternative minibuffer completion > system like Icomplete or Vertico is used, the *Completions* buffer is > not needed since the candidates are already displayed in the minibuffer. That's not what I see here. Recipe: 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? > I propose to either detect these alternative completion systems (e.g., > by checking the value of the completing-read-function and/or the mode > variables) or to provide a way to disable the call to > `minibuffer-completion-help'. > > Since the same problem is present in tmm.el, maybe a generic solution > could be provided by minibuffer.el? Option 1: A function > `minibuffer-completion-help-if-needed' could call > `minibuffer-completion-help' only if no other completion system is > detected. Option 2: A new function > `completing-read-display-help-function' could be added which defaults to > `minibuffer-completion-help' and which could be set to nil/ignore by > alternative completion UIs like Vertico. This function could be used by > tmm/ffap. Option 3: A new variable `minibuffer-inhibit-completion-help' > could be added which is checked by `minibuffer-completion-help' and > which could be set to t by alternative completion UIs. Option 2 is adding complexity to an already devilishly complex code, so I like it the least. But first I think we need to understand the problem better; see above.