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

Previous Next

Full log

Message #89 received at 67661 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 67661 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Eshel Yaron <me <at> eshelyaron.com>, 67001 <at> debbugs.gnu.org
Subject: Re: bug#67661: 30.0.50; *Completions* has started popping up for
 icomplete-in-buffer
Date: Wed, 20 Dec 2023 19:14:49 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.