From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer Date: Sat, 09 Dec 2023 14:08:45 +0100 Message-ID: References: <87o7f3e4cb.fsf@melete.silentflame.com> <83wmtr2mye.fsf@gnu.org> <87lea3wpai.fsf@zephyr.silentflame.com> Reply-To: Eshel Yaron Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4374"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 67661@debbugs.gnu.org, Eli Zaretskii , 67001@debbugs.gnu.org, Juri Linkov To: Sean Whitton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 09 14:10:09 2023 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 1rBx5t-0000ty-F6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Dec 2023 14:10:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rBx5c-0006L9-US; Sat, 09 Dec 2023 08:09:52 -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 1rBx5Z-0006KR-5a for bug-gnu-emacs@gnu.org; Sat, 09 Dec 2023 08:09:49 -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 1rBx5Y-0001JE-Q9 for bug-gnu-emacs@gnu.org; Sat, 09 Dec 2023 08:09:48 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rBx5m-0007a0-4R for bug-gnu-emacs@gnu.org; Sat, 09 Dec 2023 08:10:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Dec 2023 13:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67661 X-GNU-PR-Package: emacs Original-Received: via spool by 67661-submit@debbugs.gnu.org id=B67661.170212734929052 (code B ref 67661); Sat, 09 Dec 2023 13:10:02 +0000 Original-Received: (at 67661) by debbugs.gnu.org; 9 Dec 2023 13:09:09 +0000 Original-Received: from localhost ([127.0.0.1]:46969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBx4u-0007YR-EB for submit@debbugs.gnu.org; Sat, 09 Dec 2023 08:09:08 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16]:44666 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBx4o-0007Y8-6a; Sat, 09 Dec 2023 08:09:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1702127328; bh=kZyjeRPWfVvS/GEmXxkJAPDlBfAI8YWJSCq00o7H+p4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=arVh8rNutM0iPqv4FVqd4MhGdhA5RwAOxzEioY4O2H2rxaJrZKkEZX3TEyjvuMgba kbfL2B04ErP0wyPHH06A6qefVDX7d6bfSaMqjHsY2aoEpIaWEfFlT5A+/242hss8Uv VlPXnQOapseMVq7kG8CyNrhuw/qyFFsPQnXvPRdNe8XEd6erdesTjvBdlGpdIWKYge T/SGtsyTyWq2d/2KOZ3n58cNhLarxD/xuTu7jefA7Of7DyqfmDLmzWzzn/rBgrwel8 M3z4f6CrHzPEKJV36NizeYxEoBzdjpT2krUuQqg+Vam8mVTeN8BsMQCubQdudbmAwE B/Xj6q4xZTGRQ== In-Reply-To: <87lea3wpai.fsf@zephyr.silentflame.com> (Sean Whitton's message of "Sat, 09 Dec 2023 12:09:25 +0000") 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:275848 Archived-At: Hi Sean, Sean Whitton writes: > Previously you would get the icomplete in buffer completion. Now, > additionally, *Completions* pops up, but it doesn't make sense to have > both. I agree that having both interface together is a bit much, but AFAICT that has been the case at least since Emacs 27 whenever the text before point was the longest common prefix of several completion candidates. For example, try completing "l" instead of "ls" in eshell. On both Emacs 27 and on master, this shows both the *Completions* buffer and the in-buffer `icomplete` interface. Is this what you get as well? Sean Whitton writes: > Hello, > > On Wed 06 Dec 2023 at 08:41pm +02, Eli Zaretskii wrote: > >> AFAICT, the above description of the problem is inaccurate. The >> *Completions* buffer would pop up in previous versions as well, but >> only after a second TAB. Whereas the in-buffer completion would show >> after the first TAB. Now in Emacs 30 after the first TAB nothing >> happens, and after the second TAB you see the same display as >> previously after the second TAB: both in-buffer completion and the >> *Completions* buffer popped up. >> >> So I think the problem is that the first TAB does NOT show in-buffer >> completion anymore in the above scenario. > > Commit 5416896d608 is responsible for the problem. > It would seem that it turns off completion-in-region-mode too early. IIUC, the problem of showing both interfaces is inherent to how `icomplete-in-buffer` is implemented. It's just that in this case of completing "ls" the *Completions* doesn't show up at first because it's an exact match. What allowed the `icomplete` to show up is that although the *Completions* buffer wasn't shown, `completion-in-region-mode` would remain on, and that caused only the `icomplete` interface to appear in this specific case. The reason we now disable `completion-in-region-mode` when it doesn't show the *Completions* buffer, is to avoid having the key bindings that this minor mode sets up from lingering and shadowing other bindings. If it doesn't make sense for `icomplete-in-buffer` to appear along with the *Completions* buffer, perhaps `icomplete-in-buffer` should simply be an alternative `completion-in-region-function`? Best, Eshel