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

[Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>>
>> Sean Whitton <spwhitton@spwhitton.name> 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?
>> [...]
>> IIUC, the problem of showing both interfaces is inherent to how
>> `icomplete-in-buffer` is implemented.
>
> 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.

>> 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?