From unknown Mon Jun 23 11:25:20 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#74617 <74617@debbugs.gnu.org> To: bug#74617 <74617@debbugs.gnu.org> Subject: Status: 30.0.92; ffap-menu always displays the *Completions* buffer Reply-To: bug#74617 <74617@debbugs.gnu.org> Date: Mon, 23 Jun 2025 18:25:20 +0000 retitle 74617 30.0.92; ffap-menu always displays the *Completions* buffer reassign 74617 emacs submitter 74617 Daniel Mendler severity 74617 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 02:02:34 2024 Received: (at submit) by debbugs.gnu.org; 30 Nov 2024 07:02:34 +0000 Received: from localhost ([127.0.0.1]:45207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHHUw-0006FV-87 for submit@debbugs.gnu.org; Sat, 30 Nov 2024 02:02:34 -0500 Received: from lists.gnu.org ([209.51.188.17]:54804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHHUu-0006FJ-2f for submit@debbugs.gnu.org; Sat, 30 Nov 2024 02:02:32 -0500 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 1tHHUr-00022b-4Q for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 02:02:31 -0500 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1] 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 1tHHUo-0007zY-KY for bug-gnu-emacs@gnu.org; Sat, 30 Nov 2024 02:02:28 -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: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GqtCkYtXt/iZoWXRKNAdegMM4X5Ihpq9/YKj8pw1+Zg=; b=M9Y6ZuGJ3b63YHvzSWFjExpdlQ Arn2klWuHbfkurY7nOwWy/XjN7jtecPe1W9ztC3xW8MS9NBv57DGxC553WG9LraeJpT/5H6epDoSx khgO7jSzsbuOwQUjalA36TdfmSga/VrsR1ZIRlg1fTfipHcvwXZahKSbUGEno0woM3VM=; From: Daniel Mendler To: bug-gnu-emacs@gnu.org Subject: 30.0.92; ffap-menu always displays the *Completions* buffer X-Debbugs-Cc: Stefan Monnier Date: Sat, 30 Nov 2024 08:02:20 +0100 Message-ID: <87r06turur.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a01:4f8:c012:9177::1; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) `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. 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. I am happy to provide a patch for any of these approaches. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 03:19:55 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 08:19:55 +0000 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 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 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==; Date: Sat, 30 Nov 2024 10:19:34 +0200 Message-Id: <86ser99lrd.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: <87r06turur.fsf@daniel-mendler.de> (bug-gnu-emacs@gnu.org) Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer References: <87r06turur.fsf@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74617 Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 03:34:23 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 08:34:23 +0000 Received: from localhost ([127.0.0.1]:45330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHIvm-0002Zo-Rs for submit@debbugs.gnu.org; Sat, 30 Nov 2024 03:34:23 -0500 Received: from server.qxqx.de ([49.12.34.165]:41677 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHIvk-0002ZT-1L for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 03:34:21 -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=6d3WwWcOVbCs4oqIYuiyoKXfCM3y13weoG6YgXt4/Uw=; b=lwzcIwSlVbAkVCwnv1UyDU5g4s rf4ohud+e8UsmJMYg7071JiDuWblyPv4nEcZ5NxnTGwYypcI7jHECELyMHQH6TkFWSWvm9Tci34yx ptkeodAV2w4TsOV8zhlOKtMbbGPESuJZoLRumfkM6Aqv0u3gXX7GFwOTmlo84XWONfnE=; From: Daniel Mendler To: Eli Zaretskii Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <86ser99lrd.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Nov 2024 10:19:34 +0200") References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> Date: Sat, 30 Nov 2024 09:34:11 +0100 Message-ID: <875xo5unlo.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> 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? 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. 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'. Daniel From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 04:28:25 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 09:28:25 +0000 Received: from localhost ([127.0.0.1]:45406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHJm4-0005Im-Qd for submit@debbugs.gnu.org; Sat, 30 Nov 2024 04:28:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHJm2-0005IY-SO for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 04:28:23 -0500 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 1tHJlw-0005yu-Hm; Sat, 30 Nov 2024 04:28:16 -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=Wj5R2RmS8rLD95JNyazru2BXfhGhsclfnJU3led3fOg=; b=hsF3OWJipGWi SQB4mbZrC+H0SSCQ0HBBQXTkzokdBniAxe3XLj/eOjVIJUKZ6+QO2COM2KfO4QD2ACifDlBU803Ed sdFP3h70zvtBmgKm4bZRBU4NBXWOXIAH4/aCK+hWR/G10YalxXAmczJhFLcWWVU1LIR9aJnKB8cmX 1Si4viXw+yz6N/2mu6cZ6k6NtBEgEe17/kYSXGFWk0Js0gpTIkEQClDPnmJ24DVRC+reaZZVxnrUH pb13QB4bXqhG323NhrQMK/qWKpvf2qlcpzXxIuLMxg9d+4WgXfg4XS/0LhovvTyvs6656hfoz+IhI YaW5jWV/2TM6zW/hHxfjgA==; Date: Sat, 30 Nov 2024 11:28:13 +0200 Message-Id: <86frn99iky.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: <875xo5unlo.fsf@daniel-mendler.de> (message from Daniel Mendler on Sat, 30 Nov 2024 09:34:11 +0100) Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74617 Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. > 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 04:42:27 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 09:42:27 +0000 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 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=; From: Daniel Mendler To: Eli Zaretskii Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <86frn99iky.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Nov 2024 11:28:13 +0200") References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> Date: Sat, 30 Nov 2024 10:40:05 +0100 Message-ID: <8734j9ukju.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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'. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 07:32:59 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 12:33:00 +0000 Received: from localhost ([127.0.0.1]:45867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHMeh-0006e9-Fb for submit@debbugs.gnu.org; Sat, 30 Nov 2024 07:32:59 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHMef-0006ds-7c for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 07:32:57 -0500 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 1tHMcS-00014S-G9; Sat, 30 Nov 2024 07:30:40 -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=2wgSxCcRCRa2xOAWRBvpNwAL3FdZg217eHiFgURmlSg=; b=mLm5BhrsKMsj wgTMFGgBPRsndgl4ThShxeqcyEev8TkNWdS3sTvO4qMB04+ibniKON2gljUzGUHY1xXTINet+CPco AEZqQTWHTe9ba3PkXHxZCVHWaOe7BIvnpQCu61LFbWv9mVTPZPHIm0JQv2Dm6SUYf9MDkQkgISlYG T1dS3V4tqLHTzxKiWljCYodkBS8bVd7sKazlS+LVTQSW1zNxUQwpLO6ISIOAOTj7RKQQZmvMn5bgd zDxpra0tTwwuubsn1VNLUvqm9yN/1Vr8+ShZ2T2twbq3w44+Wza+2borEZuvDLIDOGEoVxW8AtKbE k+4Nl4EjCllcw+vAOFJT6w==; Date: Sat, 30 Nov 2024 14:30:32 +0200 Message-Id: <86v7w47vkn.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: <8734j9ukju.fsf@daniel-mendler.de> (message from Daniel Mendler on Sat, 30 Nov 2024 10:40:05 +0100) Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74617 Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Mendler > Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca > Date: Sat, 30 Nov 2024 10:40:05 +0100 > > Eli Zaretskii writes: > > 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. I don't understand: ffap-menu calls completing-read, so what abstraction does it bypass, and how? > It is not the responsibility of > alternative completion UIs to work around this. Work around what? > 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. The question is: who should pay attention and understand that "the other" completion is being called? > >> 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'. You assume that the completion table is never passed to inner levels? Is that assumption solid? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 11:27:32 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 16:27:32 +0000 Received: from localhost ([127.0.0.1]:48411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHQJf-0002mv-M3 for submit@debbugs.gnu.org; Sat, 30 Nov 2024 11:27:32 -0500 Received: from server.qxqx.de ([49.12.34.165]:42903 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHQJd-0002mg-5B for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 11:27:30 -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=KDgje/6HD2v+Ap5lfeJFPJVlCPpO7rFeYW8CABaUwys=; b=lGSHFCy8UuGVdnxkeAhMEKoLvt kFc0fp/ZEBUtkG5MF1oETljxOOqAcCi0u0a89ziHRwxEhchDI24QCuvihZxih0kEE54FwyjT7PWpp YZ6/LvTXB4ZX5beEpFLetqTYhlYMj4KIxPlDAx9h9IZnr0Snrcc21OqyPrP+Ogi81du4=; From: Daniel Mendler To: Eli Zaretskii Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <86v7w47vkn.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Nov 2024 14:30:32 +0200") References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <86v7w47vkn.fsf@gnu.org> Date: Sat, 30 Nov 2024 17:25:07 +0100 Message-ID: <87zflgit98.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Daniel Mendler >> Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca >> Date: Sat, 30 Nov 2024 10:40:05 +0100 >> >> Eli Zaretskii writes: >> > 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. > > I don't understand: ffap-menu calls completing-read, so what > abstraction does it bypass, and how? It also calls `minibuffer-completion-help' which belongs to the default completion UI but not strictly to the abstract `completing-read' API. Unfortunately the API boundaries are not clearly defined. In principle one could separate the generic `completing-read' code from the default completion UI code. This could help keeping the complexity of the completion code in check. Right now the default completion UI code is scattered across minibuffer.el and simple.el. >> It is not the responsibility of >> alternative completion UIs to work around this. > > Work around what? Hiding the *Completions* buffer. It should not be shown in the first place if the user replaced the `completing-read-function' with something else by turning on the mode of an alternative UI. >> >> 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'. > > You assume that the completion table is never passed to inner levels? > Is that assumption solid? Yes, as far as I can tell. Completion can work well in recursive minibuffers, such that the inner completion session does not interfere with the outer session. Stefan even changed the scope of the `minibuffer-completion-table' variables a while ago, such that it is only bound buffer-locally in the minibuffer. Earlier it was let-bound around the `read-from-minibuffer' call. (Of course it is still possible to access the completion table by reading the buffer local variable from the minibuffer directly, but this doesn't happen accidentally.) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 11:59:49 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 16:59:49 +0000 Received: from localhost ([127.0.0.1]:48481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHQov-0004PT-GF for submit@debbugs.gnu.org; Sat, 30 Nov 2024 11:59:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHQos-0004PB-NZ for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 11:59:47 -0500 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 1tHQom-00088z-Hr; Sat, 30 Nov 2024 11:59:40 -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=RKFwZJs67XpR/mD8a+iGAyeYTk37kmcuD+ZqWlhQhHQ=; b=PCOqbDx8MM72 h9cclt1bkzkMhGbvYZoak1gX2aNrT2NQqCpjgl+EY+YHMsVdcFvvtVWbhAZ9MyC7PYtVkeJUPliiV 5JK9CjC84hXzRHGtwDAaE853HITEnET7SmpU2dChNQXaL3La/a/LTEUP2jecdlx5nIhV09AjP62uN lkf1chgTpP4MhyE4fvL2C1hyRjKQ/AinRrA32VwPev7xzHW/nQpIYRfVisFHrF1QJhCJehTsRD6K6 9AYFSsahhUnF2N26Ivq4t8x0okYUviR8r8m8YPc8ymqZL2uzVTG/QEQ5/CplxaMhzjXQOD00QOUgu 3THi7BMGcdsXB7yEAlJAHQ==; Date: Sat, 30 Nov 2024 18:59:20 +0200 Message-Id: <86bjxw7j4n.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: <87zflgit98.fsf@daniel-mendler.de> (message from Daniel Mendler on Sat, 30 Nov 2024 17:25:07 +0100) Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <86v7w47vkn.fsf@gnu.org> <87zflgit98.fsf@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74617 Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Mendler > Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca > Date: Sat, 30 Nov 2024 17:25:07 +0100 > > Eli Zaretskii writes: > > >> 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. > > > > I don't understand: ffap-menu calls completing-read, so what > > abstraction does it bypass, and how? > > It also calls `minibuffer-completion-help' which belongs to the default > completion UI but not strictly to the abstract `completing-read' API. So the problem is this single line? (let ((minibuffer-setup-hook 'minibuffer-completion-help)) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 12:18:54 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 17:18:54 +0000 Received: from localhost ([127.0.0.1]:48871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHR7N-0005l3-Og for submit@debbugs.gnu.org; Sat, 30 Nov 2024 12:18:54 -0500 Received: from server.qxqx.de ([49.12.34.165]:49077 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHR7L-0005kk-45 for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 12:18:52 -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=KTho45xFvVZHxHyR1Sg23xpTkw46nWIBaU82NliYDzA=; b=bPmtWYFuE3vkhEDZ6NVicplWLk o0djX+N3bAp5BCImEXQibiWAJ9PUoLOoAiyoQQggaVjo/nrgkQ5LbqbjwjnJQLG3hxKNpHlu4YCl6 RWP3GwYqyIkuwuSP/lXJn3a64Fk+h0lubbLZN+2+bflEMJ7pWXNQT746y9vTqBiHWUkM=; From: Daniel Mendler To: Eli Zaretskii Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <86bjxw7j4n.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Nov 2024 18:59:20 +0200") References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <86v7w47vkn.fsf@gnu.org> <87zflgit98.fsf@daniel-mendler.de> <86bjxw7j4n.fsf@gnu.org> Date: Sat, 30 Nov 2024 18:18:43 +0100 Message-ID: <87ttboiqrw.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Daniel Mendler >> Cc: 74617@debbugs.gnu.org, monnier@iro.umontreal.ca >> Date: Sat, 30 Nov 2024 17:25:07 +0100 >> >> Eli Zaretskii writes: >> >> >> 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. >> > >> > I don't understand: ffap-menu calls completing-read, so what >> > abstraction does it bypass, and how? >> >> It also calls `minibuffer-completion-help' which belongs to the default >> completion UI but not strictly to the abstract `completing-read' API. > > So the problem is this single line? > > (let ((minibuffer-setup-hook 'minibuffer-completion-help)) Yes. But maybe it makes sense to tackle the "immediate candidate display problem" more generally. It would be great to get Stefan's input on this. For example in my osm.el package I have the following code to implement immediate display of candidates. The lambda implements the auto-detection, which I don't find particularly elegant. (minibuffer-with-setup-hook (lambda () (when (and (eq completing-read-function #'completing-read-default) (not (bound-and-true-p vertico-mode)) (not (bound-and-true-p icomplete-mode))) (let ((message-log-max nil) (inhibit-message t)) ;; Show matches immediately for default completion. (minibuffer-completion-help)))) (completing-read ...)) Initially I had forgotten the call to `minibuffer-completion-help' since most of them time I use a completion UI which displays the candidates automatically anyway. Then Richard reported the bug, that `osm-search' doesn't work conveniently in Emacs by default. Furthermore in my jinx.el package I have almost exactly the same code in `jinx--correct-setup', which is used like this: (minibuffer-with-setup-hook #'jinx--correct-setup (completing-read ...)) Daniel From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 13:18:32 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 18:18:32 +0000 Received: from localhost ([127.0.0.1]:48966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHS35-0000Pr-Lv for submit@debbugs.gnu.org; Sat, 30 Nov 2024 13:18:31 -0500 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:49549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHS33-0000PQ-HG for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 13:18:29 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 614EEFF803; Sat, 30 Nov 2024 18:17:59 +0000 (UTC) From: Juri Linkov To: Daniel Mendler Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <8734j9ukju.fsf@daniel-mendler.de> (Daniel Mendler via's message of "Sat, 30 Nov 2024 10:40:05 +0100") Organization: LINKOV.NET References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> Date: Sat, 30 Nov 2024 19:46:38 +0200 Message-ID: <87h67obon5.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: Eli Zaretskii , 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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'. And imenu.el calls minibuffer-completion-help conditionally unless imenu-eager-completion-buffer is not nil. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 13:39:14 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 18:39:14 +0000 Received: from localhost ([127.0.0.1]:49022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSN8-0001be-Aq for submit@debbugs.gnu.org; Sat, 30 Nov 2024 13:39:14 -0500 Received: from server.qxqx.de ([49.12.34.165]:60875 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSN6-0001bI-3r for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 13:39:13 -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=rxrN2w4mzegmp8RWTdxWuWCnalryR97YA2bKn3QHTkw=; b=RSm9h1hlT2EUft9F/7UStPWOIZ yILVNEqpPamB550CYkfUxa/E228l/nvX1eoL9L7MuwsohQS2QK23izIPCalGxZBqavTk/PRgXx5X/ ZNTzes7dI23cPaT1+iNerenTKjTeE3JnDbI6Bm0zkTscqTljZwufdeqwzADpdX8yeWzE=; From: Daniel Mendler To: Juri Linkov Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <87h67obon5.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 30 Nov 2024 19:46:38 +0200") References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <87h67obon5.fsf@mail.linkov.net> Date: Sat, 30 Nov 2024 19:39:03 +0100 Message-ID: <87r06sin20.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: Eli Zaretskii , 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Juri Linkov writes: >> 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'. > > And imenu.el calls minibuffer-completion-help conditionally > unless imenu-eager-completion-buffer is not nil. Thanks, I wasn't aware of this option. It seems the behavior is inverted? The completion buffer pops up if imenu-eager-completion-buffer is nil. (defcustom imenu-eager-completion-buffer t "If non-nil, eagerly pop up the completion buffer." :type 'boolean :version "22.1") It is likely that there are more such uses in the Emacs code and other packages. One possible solution would be a display-eager metadata: (completing-read "Test: " (lambda (string pred action) (if (eq action 'metadata) '(metadata (display-eager . t)) (complete-with-action action #'read-file-name-internal string pred)))) This pushes the responsibility of displaying the candidates to `completing-read'. In `completing-read-default' the following code would have to be added to the `minibuffer-with-setup-hook': (when (completion-metadata-get (completion-metadata "" minibuffer-completion-table nil) 'display-eager) (minibuffer-completion-help)) Daniel From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 13:59:34 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 18:59:34 +0000 Received: from localhost ([127.0.0.1]:49066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSgo-0002em-C9 for submit@debbugs.gnu.org; Sat, 30 Nov 2024 13:59:34 -0500 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:55527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSgn-0002eM-48 for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 13:59:33 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id A79B2240003; Sat, 30 Nov 2024 18:59:05 +0000 (UTC) From: Juri Linkov To: Daniel Mendler Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <87r06sin20.fsf@daniel-mendler.de> (Daniel Mendler's message of "Sat, 30 Nov 2024 19:39:03 +0100") Organization: LINKOV.NET References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <87h67obon5.fsf@mail.linkov.net> <87r06sin20.fsf@daniel-mendler.de> Date: Sat, 30 Nov 2024 20:58:04 +0200 Message-ID: <878qt08s77.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: Eli Zaretskii , 74617@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> And imenu.el calls minibuffer-completion-help conditionally >> unless imenu-eager-completion-buffer is not nil. > > Thanks, I wasn't aware of this option. It seems the behavior is > inverted? The completion buffer pops up if imenu-eager-completion-buffer > is nil. Unfortunately, it is inverted indeed. And there is even bug#52389 about this, but it can't be changed for backward-compatibility reasons. > It is likely that there are more such uses in the Emacs code and other > packages. One possible solution would be a display-eager metadata: > > (completing-read "Test: " > (lambda (string pred action) > (if (eq action 'metadata) > '(metadata (display-eager . t)) > (complete-with-action action #'read-file-name-internal string pred)))) > > This pushes the responsibility of displaying the candidates to > `completing-read'. In `completing-read-default' the following code > would have to be added to the `minibuffer-with-setup-hook': > > (when (completion-metadata-get > (completion-metadata "" minibuffer-completion-table nil) > 'display-eager) > (minibuffer-completion-help)) Adding a new metadata item looks like the right thing to do. Then it will be possible to configure it via completion-category-overrides. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 14:09:33 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 19:09:33 +0000 Received: from localhost ([127.0.0.1]:49108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSqS-0003Dd-W0 for submit@debbugs.gnu.org; Sat, 30 Nov 2024 14:09:33 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSqQ-0003DL-N5 for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 14:09:31 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4A244100055; Sat, 30 Nov 2024 14:09:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1732993764; bh=C9uRwYIS9T27yOlLM2DFe46PgBwo34GzYYavmh0q6QM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FVlF5lpoDbtLy08BIeK0a5tS6oy17oxnZlA3Sv/p7IErZj14WEYPF6AKOo61GuYMO AEhlk559Q6uDh033xfh574teMXVUWu4lVY/iCBCoqk71RyngFZRXF+qF8M+3T+6sJ9 Sr+jMSW3zC9B0Bq4Vqw7auzWs6LfN5kc9j6XqxMfvhfFgJhQJ/TbKjAj1Q8EBs7+yb oigyqiAUiacjLxbBdWM2H+cd2XFlK1uZpj9Jvk1PaijaP5ZxCb8+lDfZjTYVb3VLW/ G1IW3tCFHyN9u/UghG5eabZhh7waWW1niWm4NHFqMZY09K46NXKeGOkdnNRxhUN88m J1W3B+uY/NxAA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9E941100042; Sat, 30 Nov 2024 14:09:24 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 70FE6120280; Sat, 30 Nov 2024 14:09:24 -0500 (EST) From: Stefan Monnier To: Daniel Mendler Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <87zflgit98.fsf@daniel-mendler.de> (Daniel Mendler's message of "Sat, 30 Nov 2024 17:25:07 +0100") Message-ID: References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <86v7w47vkn.fsf@gnu.org> <87zflgit98.fsf@daniel-mendler.de> Date: Sat, 30 Nov 2024 14:09:23 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.021 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74617 Cc: Eli Zaretskii , 74617@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > It also calls `minibuffer-completion-help' which belongs to the default > completion UI but not strictly to the abstract `completing-read' API. Maybe `minibuffer-completion-help` should call a `minibuffer-completion-help-function`, so that it shows the help using the user's favorite UI? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 14:13:55 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 19:13:55 +0000 Received: from localhost ([127.0.0.1]:49119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSuh-0003Ru-Er for submit@debbugs.gnu.org; Sat, 30 Nov 2024 14:13:55 -0500 Received: from server.qxqx.de ([49.12.34.165]:50669 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSue-0003Rb-Re for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 14:13:53 -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=mJYU/YUYW239QLZxLqXZsbbxev/otYDz2D5hvOO7CjI=; b=G6fC+FkBKb6oHfOzgRfgMmJQY3 XpLkVu7BqU+d+LHhGRBPBJ8OatXIAov/a8/nOqZR9vhbetvVtWs+4eQyMmTiGwkcjX92yd8zw2nuo oREcVgeGI5+Y1vJSM3NBVgEGpsB+mHwFQMi2LwfJMbYQtJ+vZNkg3XLiMuDpc3EtiAsE=; From: Daniel Mendler To: Stefan Monnier Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: (Stefan Monnier's message of "Sat, 30 Nov 2024 14:09:23 -0500") References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <86v7w47vkn.fsf@gnu.org> <87zflgit98.fsf@daniel-mendler.de> Date: Sat, 30 Nov 2024 20:13:45 +0100 Message-ID: <87bjxw8rh2.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: Eli Zaretskii , 74617@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Stefan Monnier writes: >> It also calls `minibuffer-completion-help' which belongs to the default >> completion UI but not strictly to the abstract `completing-read' API. > > Maybe `minibuffer-completion-help` should call > a `minibuffer-completion-help-function`, so that it shows the help using > the user's favorite UI? Yes, this was one of the proposals I made. However this has a downside. It always prevents displaying the *Completions* buffer, while sometimes it may be desired to open it on demand. Daniel From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 16:30:49 2024 Received: (at 74617) by debbugs.gnu.org; 30 Nov 2024 21:30:49 +0000 Received: from localhost ([127.0.0.1]:49347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHV3B-0002R2-27 for submit@debbugs.gnu.org; Sat, 30 Nov 2024 16:30:49 -0500 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:57754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHV38-0002Qs-Qk for 74617@debbugs.gnu.org; Sat, 30 Nov 2024 16:30:47 -0500 Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4AUIU9nD028715; Sat, 30 Nov 2024 21:30:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2023-11-20; bh=rMlqAh1QuRMnFGsYckOAARmL2E4HLyK3uDCDB+H1GWM=; b= lE5iVB1tS0oaJ5YhIebuaJCaawddiGBFrBLQinCYaoJuVbEcAymXApHgmiGo8wvy dSF9YjWPK26OTeMrBHR7Ur9mlLbFejVtzxiWsxqJ3rmfOJSTnR+JnUn0VY67gQud W3hAL7jjp84sAgi8AlHMqDZuMdGxbiAlywnK3ZoJKOeIiDFYfbh+iAwgl5TbbNEo P+s7GadZETtkq77eIhYGhp9GWMEfmAExhxl2y+5reCTLekpg5N0HTDKvJLM6O4i2 3xGwCVNT2Gz57fWjqNKF6e3f5sMm0sdXM7qHU0ZGFf7pROg7y+9hpK6tWv+vI55K 3RBmH1zTzgv5zd1+ofPFcQ== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 437sg20tw5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 30 Nov 2024 21:30:39 +0000 (GMT) Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4AUIEMss001984; Sat, 30 Nov 2024 21:30:39 GMT Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam02lp2047.outbound.protection.outlook.com [104.47.56.47]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 437s551s1p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 30 Nov 2024 21:30:39 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aVqF/4Mm6f/FkGNKcsPcXFuYNxW7UDXTNWthoD26TnzTeU9ZfBfyi2Um0ejmSYORaNuHz+bauke3Nt1i/hcZ8cLFq3mPjckG3+PW1fDzi6QKiJfDnhBJP7eeM9FyJdG0s2WbHa1rpypvce2zxEfnMzdlJvzj9uaDxBKg9jreDCYHxQwqQH2I4T0fZ8yoDb6mY5uDmoF9HfhDanAwl0QCIpwa/22g1YXhVlQixWVKS5478tNiDAqqywXPOscOHJbR0IOwbJHa7BB5UaI7oWAGm0Cvi854KgNmwyufvKjMkKg0VCIDK+BZE/z3+dJAUSsGZvoiOQPo7vTbsUkVXYSEfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rMlqAh1QuRMnFGsYckOAARmL2E4HLyK3uDCDB+H1GWM=; b=Lr59gdMFUBbFyTbSY0Pp1PDbrfb6ApePPcFDhTeKYMmhndIRAvDpicZWPo5JzYiAKV4OBT5x/mXenXhhABn3I3OoGuf88Z/BKbHsjlkQeJTBTqVawTcOZvJMEh24NzPnwkXcME4QsyTzD6r8x/bE/FiW10wEckYhSucYxgyMyIkisG0oBmlN7yHcx3NWpZxXsMmPLUm86meLF0TjES132cYGERjmqCM8A/XtfRgQmT3LSy7BIgIoXR+IVVAvgivTWZcq1phZW4v6GA9/0Bgu2QRpkN1E+ziiILReSR6CF99ZuiKJ3jc9hoYhxxAa7PWyVq74MbLOXjreRRUzgooUJQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rMlqAh1QuRMnFGsYckOAARmL2E4HLyK3uDCDB+H1GWM=; b=jQJEChfT6iKb6BxvfrfR3rwAPPQ05fxuTi/LgO6Dq7vv0Tg0MM0IHdjVcijtZhsaIS/dMImJVddUEdtTL/wFWUP0uIGoWImVo/L1yimHbb/nbyWLKaOuOz4HoKu1M5q2/57f4XwAAh5KeKeLFFsksngf25t8E1yIKeEmHCralLY= Received: from BLAPR10MB5219.namprd10.prod.outlook.com (2603:10b6:208:321::22) by DS7PR10MB5167.namprd10.prod.outlook.com (2603:10b6:5:38e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.17; Sat, 30 Nov 2024 21:30:36 +0000 Received: from BLAPR10MB5219.namprd10.prod.outlook.com ([fe80::8179:21ba:b158:7d50]) by BLAPR10MB5219.namprd10.prod.outlook.com ([fe80::8179:21ba:b158:7d50%6]) with mapi id 15.20.8207.017; Sat, 30 Nov 2024 21:30:35 +0000 From: Drew Adams To: Juri Linkov , Daniel Mendler Subject: RE: [External] : bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer Thread-Topic: [External] : bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer Thread-Index: AQHbQ1RqVU3iievrJ0O88CRsEU/167LQU60w Date: Sat, 30 Nov 2024 21:30:35 +0000 Message-ID: References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <87h67obon5.fsf@mail.linkov.net> In-Reply-To: <87h67obon5.fsf@mail.linkov.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BLAPR10MB5219:EE_|DS7PR10MB5167:EE_ x-ms-office365-filtering-correlation-id: 7b158d20-2a96-493d-4b9c-08dd11863a29 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|1800799024|366016|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?UDsfLjbWmOi0qwvRemlyiDRmDY2WwEyxzyInA/Nu2brS+hASWRCKQXQYeVMz?= =?us-ascii?Q?o3cA7qeiauVkAynCnGfQP/m6xIYvl2jbgMWCs8TaKoJ7AFHySdi4XDV7MTN9?= =?us-ascii?Q?kfak/nQalfbLv9C6OXDezQVeASb3I010hl0eGV/uTd8J6/aOMb9u2XqWxwGo?= =?us-ascii?Q?dZJVRE3TJgc8l8aM0WYHlaALgORqSHwu3Px4j+rshNQNG5oefiU5IwOAMooM?= =?us-ascii?Q?zCwyNJ0fh9HgQwbTD5lCnIZoR0eK34WnDLimBJuLMjUWqn+uyuipvHpUU9vf?= =?us-ascii?Q?YyxQxtSO8qVcqWIa2GDR3t2U319vrv6X7kZ9FYk7+uI/y0xIFEOaGvpmJhJC?= =?us-ascii?Q?/gnMxMAdNb5LoQzhBo6ILdvSDt5YSJFRClighvXuSpGzVF9+cubvheZu+AxH?= =?us-ascii?Q?BsYvovI6XF4INBOR36KLXJYLFMoSoaE1BPO0/4HnbACXcsnCiPSzHqKlqzgS?= =?us-ascii?Q?UuGG4xR20uy/xPvAFET/QeaMJNHpVPxRIkHTP+GcOFrCAQ0fo6F7H78TbKor?= =?us-ascii?Q?gDvfZOfeQ33DTkDiFIGQKI79jgXcFishFRdskN8wFJGnr8hBQHknnp/gntkD?= =?us-ascii?Q?US2SA0FhpWKGJoZVJfoGaiKnt+Flhlxy0znyU7aWfhjCErjEGYW7HEoBEeSs?= =?us-ascii?Q?VOFJjy0pDoANpmHmy9SrChYJ4q1qi/3Po21SE4XYS6rRz0OgcvJrbguVpk2i?= =?us-ascii?Q?sNlio75dzJhzeT6bubTvCGj8pC7AoNzeHmrx5AtA84xFWbj4MuVLUDlDB8Pz?= =?us-ascii?Q?qdtLZylqdANkahj2EvKNxEspAQzf5R62Oln/9LzfFwgoCo2Q5HXLrkb221wl?= =?us-ascii?Q?sRj7njNmS9bePv1Aqd3qJU3UITjd3OkJRybDTwwi+iVuaPMPyA28phjo47C/?= =?us-ascii?Q?UWPuraZ9DgpAtMbhEiMn8Clrf0zA72Z3/wT81Uy0ztgmH7S/jgv1Xrb6bNTO?= =?us-ascii?Q?3m5cA8GhwwDkFARqzxX/XM4QIF5NUOwnFZUQ+TXB0gJiisSo6DUSumsQVDds?= =?us-ascii?Q?eH3BEmcjxY+q2HZf5iFZxQEQXG1cEnf8ATcWU+HhYK1b+b4+iNlJGX7Q6tkL?= =?us-ascii?Q?LJGDqjhdbNVaw5TAJTtj19spVgl7a3BQmH4bwE6inLof3dX52579vzJhyWyf?= =?us-ascii?Q?aEMw5cVlSmXmXRLJWlaikKJQjVGXGecWSLZU1JuEHxMhA/iqafTjXR1XSCmu?= =?us-ascii?Q?wdyK2CO3Asba9KCgQNbDMFq1xx1WAHJinO199/be0jz9uBO0tly24fgSgFxC?= =?us-ascii?Q?rOw2o0I+9uGj96c98oy5G8aN8f/fzAejUQYelZFkGRJX241mpPC3taUmWb25?= =?us-ascii?Q?h+v+XnNm3U8Sm2eBECIYy2Wg238cjN2jB3rm76YT7fvPoiE1jjMj84AYUnXb?= =?us-ascii?Q?oi5xAs2fLa9attURX5xG+ImUO6cyowrrIiyIegaeodOzpnaWfQ=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR10MB5219.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(366016)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Yo47nWavgaajO4ZLul+NFzhiPTpGcYYcT3+z9qyDZ01m0sTVO3LyC73olL/a?= =?us-ascii?Q?de3x4zWHzLCDqpSVwQmP6Y6bt0WsDIWxKoXPjMii4JnK9pFUOWbB/jeMewf1?= =?us-ascii?Q?IfR3fF3HXcIQuRwySXIfuTHexuximlE7xBJEWsbsC04cSN+aCZvOqEm4S1kQ?= =?us-ascii?Q?fuCX0O42BmoaMPnOzfwn0XO6PNQeLt6Ti1NyqK3rI+I3oYOGKp2ferlg7WOO?= =?us-ascii?Q?iBRtn0x5sPQGnQJ9VyTjZB3QIs+YXQMKY8xGleZZ1qTFARn8L1kszeQ3GXgX?= =?us-ascii?Q?7DbUBrl1NduGAniN9+bOx4k7IBI1dyyGR46vkCdHWRItimsSoVvS91mAKSSR?= =?us-ascii?Q?CqheQdbEE2lL0tfa5aKlcodrWTCmHEBPAk/Bo8ur2VOzduqFJ/RJn/S0TsBW?= =?us-ascii?Q?owEEjyhwzjuw0/PE8jMa07hpIN9FKMd177kCpWszcsfkGQEHQYI4feP48lbh?= =?us-ascii?Q?z91CFcF8HBSO+511ijdVzjUxJ55zmrQu3sU1KDTIq4S/sTYTWLDdLW4mHgGV?= =?us-ascii?Q?zNaTKXMykXAwN9NRTSjouacWyYVKLNI3QTpmrk3t+oQRI0Vizb3s7YvRnVTQ?= =?us-ascii?Q?wxZtarafcGE7JvyBXph2iBH09hrLECv3O1v9rTx6VmkEdwR8WxLXuGIiVzM5?= =?us-ascii?Q?ctcs2us43sXz6P62aS9MIxa/IiYbpYQZY2C2l7CM3zHj2ZvaQA88AhovZjAK?= =?us-ascii?Q?ZsoTzthPlFeT99yRHEBvfIzPM7W5Wjs6Qafv+iZzsG/kR1dDlWNKfEZ0Sfvh?= =?us-ascii?Q?/gs0pTSek4MdrsFmCCRBfmjbDjZWsZ+Muc+xV0oNi04dYGj2RXR1UiroQe7V?= =?us-ascii?Q?oS1+k5OMnnFnu95df7Wm/KHQLhHVHu34SpAhV2su65Mcl/27ru2NVZZ7luvi?= =?us-ascii?Q?+QoZPdnyJqwCHxCM+zETVxolZyVu/P3o+NJLpvCtwz+MEi1n4EiLmFpLF8P9?= =?us-ascii?Q?4wGTB6xHdWgBtokPembV/hs0gs59HUSpAzlCS5jnJTxW4v+1A5Iv6aFHy3v4?= =?us-ascii?Q?UiCiRKvfSxwimM92zrHwSbeqsnqXWHR9X3z7EC3gLEjj25To9GoGyk9qUw78?= =?us-ascii?Q?CQhmPwyeZBGPdaoYrvSYkeMlJl4svfK9YQjEWhPsOZw5704WEuwJoyjMO0fH?= =?us-ascii?Q?gTJi2azJn4692K0wm/PK0P4b8mAXvJjeGzUAT8rXRiCm5q5/8qBGKJ26E+4v?= =?us-ascii?Q?OlgWBgn6VTdljP0bSxJVHZXqQsm+pOGWjfQMPvaqGbVv9iYEb4vPmGYuOrD0?= =?us-ascii?Q?n+uTDzYlQsnE6xeUjw6I7vA+SS0eKLw+HRwf8iInBkZDFVcBj5IxAlFZk41u?= =?us-ascii?Q?09DnFXvIPccddwgIZvTKec56kjKyVHKs7+D/+kMJqLaa10SnJIjeOXSRbUZ1?= =?us-ascii?Q?8aFL9ZLxXR2dhRapuChOvRVh3c1cnsqet+3hx6hXaKUV5NkK8hB3BZTpPMU1?= =?us-ascii?Q?RcuhpqN0XiAakDSOeMDoO0tcq1SxRpW1D07PlOX8YJerz7bPB6EeBzTvVGj8?= =?us-ascii?Q?5GkxA8YeoWDcCEfkxpCQtgwftx3dhkvN7OVaWdkaX2J05bwoNyGion2r4iSz?= =?us-ascii?Q?eAbKZG4G3WF0348VzW8Lmr2EmQq8mQLzMPKjKUOC?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: CkcYcnzqyDj22JgvJW9FZqN8WcVqDi2rzSUNJ2igX8ZwxpBdRPuU2vOX85onUuOM0biO1cPgdlJWRwr2QH19lUr0aXb1rh332p0xjyfBLAK1679QRm3dU2KFsG5VhbKFrkKzxevWrPp2hvZsbd1L8cdwGS4m+daRKtxQDQ/kU6QuPfp7aBgtX9QFK8JTjMvpeU0VybzUbfMMVRtfc4DftPtL6mkhEWCsI4WVa7zGds/aTx2CyKVbUSkykWi0GEx8WjYqeoLcFiOc/hwdZVhitf15p7xk/kCvhPoQrnYBB+r2DEpBIZP+1Hj54aqgFxZqHHmwtSo18VoDoJgu///obMwEFP/MsLABGutA5bmNMxjTL1W2OwFxTAl0B4eicrqPRwLlt1nqjYBOmMwJN0ZyqJfqPJV5ILI6Pv2+4mdFQcmN4KS0lhs+PgP55Xc8gzjDDKs/ulDoZWsk8z7/dgluCDpWdH64j+/qrvYZC/ogTSvXVq+q4OTkcU1GiJaWvEqLX5PDdM5rKs0FE5h4Zv8BZGNCTnaHRem36eJEMVoL6mfUErz0gVUcPQdwHAODxEs699uyEwNmJ1Lhbo1nrnwySDef0MPltZmsE3HvQdxPeQE= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB5219.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b158d20-2a96-493d-4b9c-08dd11863a29 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2024 21:30:35.5084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bOxnl/iPMrmU7iPiKQMDTxPYjQYPG2JskVKZ2Lr0i9jsjC2pgtLQKoYH7/4Sqh9k+saozBe3dl35J/BE1jmUTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB5167 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-11-30_17,2024-11-28_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2411300183 X-Proofpoint-ORIG-GUID: j2oAMpdNEyoMcOi_yQ2VDkpL5ov6_ocb X-Proofpoint-GUID: j2oAMpdNEyoMcOi_yQ2VDkpL5ov6_ocb X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617 Cc: Eli Zaretskii , "74617@debbugs.gnu.org" <74617@debbugs.gnu.org>, "monnier@iro.umontreal.ca" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > 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'. >=20 > And imenu.el calls minibuffer-completion-help conditionally > unless imenu-eager-completion-buffer is not nil. `minibuffer-completion-help' is above all a user command. Why should any code call `minibuffer-completion-help', other than code in minibuffer.el, or code in a command whose purpose is (at least partly) to show *Completions*? On the other hand, completion frameworks can provide other means to show *Completions* initially or show it incrementally in response to pattern input in the minibuffer. (E.g., Icicles has a user option to show candidates initially and an option that supports incremental completion.) ___ icicle-show-Completions-initially-flag is a variable defined in `icicles-op= t.el'. Its value is nil Documentation: Non-nil means to show buffer `*Completions*' even without user input. nil means that `*Completions*' is shown upon demand, via `TAB' or `S-TAB'. For an alternative but similar behavior to using non-nil for `icicle-show-Completions-initially-flag', you can set option `icicle-incremental-completion' to a value that is neither nil nor t. That displays buffer `*Completions*' as soon as you type or delete input, but not initially. Remember that you can use multi-command `icicle-toggle-option' anytime (`M-i M-i' during completion) to toggle an option value. You can customize this variable. ___ icicle-incremental-completion is a variable defined in `icicles-opt.el'. Its value is t Documentation: Non-nil means update `*Completions*' buffer incrementally as you type. nil means do not update `*Completions*' incrementally, as you type. t means do nothing if `*Completions*' is not already displayed. Non-nil and non-t means display `*Completions*' and update it. You can cycle this among the possible values using `C-#' from the minibuffer at any time. Note: Incremental completion is effectively turned off when a remote file name is read, that is, whenever your file-name input matches a remote-file syntax. See also `icicle-incremental-completion-delay' and `icicle-incremental-completion-threshold'. You can customize this variable. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 01:19:57 2024 Received: (at 74617) by debbugs.gnu.org; 1 Dec 2024 06:19:58 +0000 Received: from localhost ([127.0.0.1]:49941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHdJF-0003v9-He for submit@debbugs.gnu.org; Sun, 01 Dec 2024 01:19:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHdJD-0003up-Cp for 74617@debbugs.gnu.org; Sun, 01 Dec 2024 01:19:56 -0500 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 1tHdGx-0002IM-M1; Sun, 01 Dec 2024 01:17:35 -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=RN7tXnlyAgeXA4wbog2QWNbXtqX+Yx6Lzzef80AdGnI=; b=NeyGbxi0orUr OGSrcO8gWwOvMsRXdPUWv1XCwtMDOTOJRXj627GgrgGSVW4oY4vZZJ1zQy3edb0WunLJe1smgd89u xL1RkNDikUG76hr2DYbm8psbn1R4kaDvZpyRpSsFLwXgTbvBVzv0TIG+9uT5791vIgYqG1/pdtgKt 6xL4eslEB0ep80qPWgdakld+PlVahIr3SO/QocHZ2WCm7ZS8A9W0yy4+aLqf7EWlk65wNvxO9ovv0 UW/+bI3Dr6Hn+Ed3hv3xbjJTMfz4uk35a73d9KASvtZrihWuT3JEyjty17UzxlbfGYTkRluOFWEc6 uH3nScVt5oAZOP45xJDbCA==; Date: Sun, 01 Dec 2024 08:17:31 +0200 Message-Id: <86zflg53lw.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-Reply-To: (message from Drew Adams on Sat, 30 Nov 2024 21:30:35 +0000) Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer References: <87r06turur.fsf@daniel-mendler.de> <86ser99lrd.fsf@gnu.org> <875xo5unlo.fsf@daniel-mendler.de> <86frn99iky.fsf@gnu.org> <8734j9ukju.fsf@daniel-mendler.de> <87h67obon5.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74617 Cc: mail@daniel-mendler.de, 74617@debbugs.gnu.org, monnier@iro.umontreal.ca, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Drew Adams > CC: Eli Zaretskii , > "74617@debbugs.gnu.org" > <74617@debbugs.gnu.org>, > "monnier@iro.umontreal.ca" > > Date: Sat, 30 Nov 2024 21:30:35 +0000 > > > > 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'. > > > > And imenu.el calls minibuffer-completion-help conditionally > > unless imenu-eager-completion-buffer is not nil. > > `minibuffer-completion-help' is above all a user > command. > > Why should any code call `minibuffer-completion-help', > other than code in minibuffer.el, or code in a command > whose purpose is (at least partly) to show *Completions*? We are talking here about a command that explicitly wants to show *Completions*. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 14 07:52:13 2024 Received: (at 74617-done) by debbugs.gnu.org; 14 Dec 2024 12:52:13 +0000 Received: from localhost ([127.0.0.1]:45854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMRcv-0007or-WC for submit@debbugs.gnu.org; Sat, 14 Dec 2024 07:52:11 -0500 Received: from server.qxqx.de ([49.12.34.165]:34933 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMRct-0007oS-Ez for 74617-done@debbugs.gnu.org; Sat, 14 Dec 2024 07:52:07 -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:To:From:Sender:Reply-To:Cc: 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=/jLGvU9/iVxzv7mnMBeNhCkSCbAwdma7DI2InPfVUDY=; b=uKrz4Dnvw8i5kgWSY10zDbCTr1 bOzqYP72+5o311FVIjpIhc7O7q180734QPFVT3V8ehxOWiQ5CrADUSdxoQB8tte71jrpieOKnpWTT Fz0j2wmAsWVosS0/NAMnr9zQ/7Lc2ze5Fyqm2yKrt/6hBzuBklYG6ovJGZ9aUMrnotWY=; From: Daniel Mendler To: 74617-done@debbugs.gnu.org Subject: Re: bug#74617: 30.0.92; ffap-menu always displays the *Completions* buffer In-Reply-To: <87r06turur.fsf@daniel-mendler.de> (Daniel Mendler's message of "Sat, 30 Nov 2024 08:02:20 +0100") References: <87r06turur.fsf@daniel-mendler.de> Date: Sat, 14 Dec 2024 13:51:56 +0100 Message-ID: <87r06aig0j.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74617-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Fixed by `completion-eager-display'. See bug#74616. From unknown Mon Jun 23 11:25:20 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 12 Jan 2025 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator