bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eshel Yaron]

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/