bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juri Linkov
Subject: bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer
Date: Wed, 20 Dec 2023 19:14:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)

>> Because ls<TAB> is complete, but not unique.  So it requires the second TAB,
>> exactly as in the minibuffer.  A single TAB does this on incomplete 
>> candidate,
>> e.g. l<TAB>.
>
> Ah.  This is not the bug.  We may have been subtly miscommunicating.
> I am talking about completing the first argument to the command, not
> the 'ls' command itself.
>
> So for example:
>
> 1. emacs -q
> 2. (setopt icomplete-in-buffer t)
> 3. M-x icomplete-mode
> 4. M-x eshell
> 5. cd ~/src/emacs/
> 6. ls l<TAB>
>
> It takes a second <TAB> to have Emacs display leim, lib, lib-src, lisp etc..

Thanks for the reproducible test case.  It seems there is a bug somewhere in
pcomplete-completions-at-point.  Without icomplete:

1. emacs -q
2. M-x eshell
3. ls l<TAB>

says "Complete, but not unique" that is not true.

There is no such problem with shell that uses comint-completion-at-point
instead of pcomplete-completions-at-point.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]