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 17:03:57 +0100 Message-ID: References: <87o7f3e4cb.fsf@melete.silentflame.com> <83wmtr2mye.fsf@gnu.org> <87lea3wpai.fsf@zephyr.silentflame.com> <8334wby0bq.fsf@gnu.org> <83y1e3wia7.fsf@gnu.org> 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="6686"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 67661@debbugs.gnu.org, 67001@debbugs.gnu.org, spwhitton@spwhitton.name, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 09 17:05:11 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 1rBzpH-0001TA-3j for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Dec 2023 17:05:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rBzoy-0000Ug-V4; Sat, 09 Dec 2023 11:04: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 1rBzov-0000UL-H9 for bug-gnu-emacs@gnu.org; Sat, 09 Dec 2023 11:04:50 -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 1rBzou-0003GT-RR for bug-gnu-emacs@gnu.org; Sat, 09 Dec 2023 11:04:49 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rBzp8-0006tJ-3I for bug-gnu-emacs@gnu.org; Sat, 09 Dec 2023 11:05: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 16:05: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.170213786026433 (code B ref 67661); Sat, 09 Dec 2023 16:05:02 +0000 Original-Received: (at 67661) by debbugs.gnu.org; 9 Dec 2023 16:04:20 +0000 Original-Received: from localhost ([127.0.0.1]:48781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBzoR-0006sC-E3 for submit@debbugs.gnu.org; Sat, 09 Dec 2023 11:04:19 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16]:58680 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBzoM-0006rw-BQ; Sat, 09 Dec 2023 11:04:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1702137840; bh=4Go6izHrQ/0SDorNr/Tq7yCZrnhedUgGsZ2R9V7PRJM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Uhs0ZSBusJpBO4sQzWoLHlI4tnacpFilemmkAL9o8gef1RhLxvsn1OiqW6C+ErEBT RHRCyyfVMHmkF8Q69T4FqwWbld3DptakyvO0KgECxcjnLiVi2DHeT43R+d4uFTpVqx 1DRxLli9CP/tyXnwCTAg6yo1gujVCbRg0XpUhwqSxUMtDpRrzphAf5tCNuKyNjRfnS U+wxjvNmUrBj9SauYaWnmZ9FnKHOmFF06y6PznVag7AUCSPZ6Nh2OVdkfZTU4IbbwL 9fk41MtSFNh5G1IeJQENWFHhTy5FUSweNAvJXeX0QDnoyeGQ25dvHEmX9We4ebnf57 a+NMKlZbRJb1A== In-Reply-To: <83y1e3wia7.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Dec 2023 16:40:48 +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:275863 Archived-At: Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: spwhitton@spwhitton.name, juri@linkov.net, 67661@debbugs.gnu.org, >> 67001@debbugs.gnu.org >> Date: Sat, 09 Dec 2023 15:13:53 +0100 >> >> Eli Zaretskii writes: >> >> > Once again, the fact that the second TAB shows both completion >> > interfaces is not the problem: as you point out that was how Emacs >> > behaved since long ago. The problem here is that the _first_ TAB does >> > NOT show in-buffer completions. >> >> Yes, but what I pointed out was that the first TAB has been showing both >> interfaces since Emacs 27, just not with this particular recipe. > > That's not what I see in Emacs 29. There' the first TAB shows only > the in-buffer completions, and the second TAB pops up the > *Completions* buffer (without removing the in-buffer completions). Did you try with "l" before point instead of "ls" as I suggested? Sean, how about you? >> >> If it doesn't make sense for `icomplete-in-buffer` to appear along >> >> with the *Completions* buffer >> > >> > Again, this is not the problem to solve. >> >> Could you explain what you mean here? If this behavior doesn't make >> sense, isn't it worth trying to solve it for all cases, rather than just >> for one specific case? > > I don't think I understand what you mean by "one specific case". > Which case, and why is it specific? I was referring to the specific case that Sean's recipe illustrated. This case exhibits a change in behavior that you clearly described, and that change is supposedly for the worse. IIUC what bothers Sean is that both interfaces appear together, but the thing is that that seems to be inherent to how `icomplete-in-buffer` currently works. > Sean reported a regression in behavior under icomplete-in-buffer, so I > looked into the recipe he posted. What I saw was that Emacs 29 shows > the in-buffer completions after the first TAB and adds to that the > *Completions* buffer after the second TAB. By contrast, Emacs 30 > shows nothing after the first TAB, and shows both in-buffer > completions and the *Completions* buffer after the second TAB. So my > conclusion was that the regression is the behavior after the first > TAB. If this conclusion is incorrect, please tell what did I miss. I think your reasoning is perfectly sound, but since already in Emacs 29 (and beforehand) both interfaces would appear together after the first TAB if you complete another string, restoring the behavior of Emacs 29 wouldn't fully address this problem. Put plainly, I'm not sure the Emacs 29 behavior of `icomplete-in-buffer` is any more intended than the current behavior. Stefan Monnier wrote[0] a couple of years ago about `icomplete-in-buffer`: I wrote it this way [as a defvar] because I consider(ed) that code just "proof of concept" and not working well enough to inflict it on unsuspecting users. Followed by: The problem is not so much in the code but in the behavior. If you think the behavior is good enough, then by all means use it, but I think it's a bit rough around the edges. I don't use `icomplete-in-buffer` myself, but seems like Sean does, so my suggestion was that we implement this in earnest as a `completion-in-region-function`, while specifying the intended behavior regarding TABs, overlays, and the *Completions* buffer. Best, Eshel [0] https://yhetil.org/emacs/jwvzgv1yec5.fsf-monnier+emacs@gnu.org/