unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 67661@debbugs.gnu.org, 67001@debbugs.gnu.org,
	spwhitton@spwhitton.name, juri@linkov.net
Subject: bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer
Date: Sat, 09 Dec 2023 17:03:57 +0100	[thread overview]
Message-ID: <m1lea3nz0y.fsf@dazzs-mbp.home> (raw)
In-Reply-To: <83y1e3wia7.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Dec 2023 16:40:48 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> 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 <eliz@gnu.org> 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/





  parent reply	other threads:[~2023-12-09 16:03 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-06 15:30 bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer Sean Whitton
2023-12-06 17:13 ` Juri Linkov
2023-12-06 18:14   ` Sean Whitton
2023-12-06 18:41 ` Eli Zaretskii
2023-12-07 11:42   ` Sean Whitton
2023-12-09 12:09   ` Sean Whitton
2023-12-09 13:08     ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-09 13:25       ` Eli Zaretskii
2023-12-09 14:13         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-09 14:40           ` Eli Zaretskii
2023-12-09 15:22             ` Sean Whitton
2023-12-09 16:03             ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-12-09 16:07               ` Sean Whitton
2023-12-09 17:19                 ` Juri Linkov
2023-12-09 19:04                   ` Sean Whitton
2023-12-10 17:46                     ` Juri Linkov
2023-12-10 21:42                       ` Sean Whitton
2023-12-11 17:15                         ` Juri Linkov
2023-12-15 12:28                           ` Sean Whitton
2023-12-19 17:29                             ` Juri Linkov
2023-12-19 18:31                               ` Sean Whitton
2023-12-19 18:58                                 ` Juri Linkov
2023-12-20 10:34                                   ` Sean Whitton
2023-12-20 17:14                                     ` Juri Linkov
2023-12-22 12:00                                       ` Sean Whitton
2023-12-23 17:38                                         ` Juri Linkov
2023-12-29 17:47                                     ` Sean Whitton
2023-12-29 18:00                                       ` Sean Whitton
2023-12-29 19:27                                         ` Eli Zaretskii
2023-12-29 20:24                                           ` Sean Whitton
2023-12-30  6:30                                             ` Eli Zaretskii
2023-12-30 10:41                                               ` Sean Whitton
2023-12-30 17:52                                                 ` Juri Linkov
2023-12-30 19:43                                                   ` Sean Whitton
2023-12-30 17:50                                             ` Juri Linkov
2023-12-30 19:43                                               ` Sean Whitton
2023-12-31  8:29                                                 ` Juri Linkov
2024-01-10  3:12                                         ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 17:55                                           ` Sean Whitton
2024-01-17 19:18                                             ` Jim Porter
2023-12-09 16:22               ` Eli Zaretskii
2023-12-07 17:28 ` Juri Linkov
2023-12-07 22:04   ` Sean Whitton
2023-12-08  6:28     ` Eli Zaretskii
2023-12-08 10:19       ` Sean Whitton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1lea3nz0y.fsf@dazzs-mbp.home \
    --to=bug-gnu-emacs@gnu.org \
    --cc=67001@debbugs.gnu.org \
    --cc=67661@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=me@eshelyaron.com \
    --cc=spwhitton@spwhitton.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).