GNU bug report logs -
#67661
30.0.50; *Completions* has started popping up for icomplete-in-buffer
Previous Next
Reported by: Sean Whitton <spwhitton <at> spwhitton.name>
Date: Wed, 6 Dec 2023 15:31:02 UTC
Severity: normal
Fixed in version 30.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
Message #41 received at 67661 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Eshel Yaron <me <at> eshelyaron.com>
>>
>> Sean Whitton <spwhitton <at> 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?
This bug report was last modified 1 year and 183 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.