GNU bug report logs - #19031
24.4; find-file in icomplete-mode shows completions with no input

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: olau <at> iola.dk, larsi <at> gnus.org, 19031 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#19031: 24.4;
 find-file in icomplete-mode shows completions with no input
Date: Tue, 08 Dec 2020 17:34:38 +0200

> From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
> Date: Tue, 08 Dec 2020 12:43:21 +0200
> Cc: Ole Laursen <olau <at> iola.dk>, Lars Ingebrigtsen <larsi <at> gnus.org>,
>  19031 <at> debbugs.gnu.org
> 
> 1. emacs -Q
> 2. M-: (setq insert-default-directory nil)
> 3. M-x icomplete-mode
> 4. C-x C-f ~/
> 
> In this case everything works as described by the docstring: user input
> is here so completions are shown.  But IMO Ole's issue is not
> completely solved: bunch of uninteresting dotfiles are shown.

Emacs never filters out the dotfiles, not by default anyway.  Try
"C-x C-f TAB TAB", and you will see that.  IMO, it would be confusing
if some completion packages did this and some didn't.

> If the 'read-file-name-default' function can set the
> 'minibuffer-default' variable to the substring of the minibuffer content
> from (minibuffer-prompt-end) to the last occurence of the path
> separator, then, in addition to the patched 'icomplete-exhibit', this
> can give desired result: no completions will be show until some input
> after path separator.

But file-name input is not limited to absolute file names.  The user
can legitimately enter a relative file name, in which case the
separator may not be present at all.

Previous Next

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