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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19031 in the body.
You can then email your comments to 19031 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Ole Laursen <olau <at> iola.dk>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4; find-file in icomplete-mode shows completions with no input
Date: Wed, 12 Nov 2014 12:25:37 +0100

Run emacs -Q, evaluate

  (icomplete-mode 1)

then press C-x C-f and wait a second. There's now completions in the
minibuffer despite icomplete-show-matches-on-no-input being nil. Perhaps
icomplete is confused by the current working dir being present in C-x
C-f.


Ole



In GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.4)
 of 2014-10-26 on x86-csail-01, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11601901
System Description:	Debian GNU/Linux testing (jessie)

Configured using:
 `configure --build i586-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --build i586-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: da_DK.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  icomplete-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f . e m <tab> <return> C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-s C-g C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-e C-x C-e C-x C-f C-g M-x r e p o 
r t C-j

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
t
Quit

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils mule-util icomplete misearch
multi-isearch time-date tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 8 73285 5828)
 (symbols 24 17705 0)
 (miscs 20 46 199)
 (strings 16 9368 4492)
 (string-bytes 1 256631)
 (vectors 8 9681)
 (vector-slots 4 394761 6372)
 (floats 8 67 147)
 (intervals 28 317 14)
 (buffers 512 12)
 (heap 1024 14530 751))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ole Laursen <olau <at> iola.dk>
Cc: 19031 <at> debbugs.gnu.org
Subject: Re: bug#19031: 24.4; find-file in icomplete-mode shows completions
 with no input
Date: Fri, 04 Dec 2020 11:35:22 +0100

Ole Laursen <olau <at> iola.dk> writes:

> Run emacs -Q, evaluate
>
>   (icomplete-mode 1)
>
> then press C-x C-f and wait a second. There's now completions in the
> minibuffer despite icomplete-show-matches-on-no-input being nil. Perhaps
> icomplete is confused by the current working dir being present in C-x
> C-f.

I think the icomplete-show-matches-on-no-input doc string is just
unclear here.  It seems like the point of the variable is that you can
set it to non-nil to force icomplete to wait until we have completions
before displaying the prompt?  When it's the default nil value, it'll
still show all the matches, but they may arrive asynchronously.

I've now clarified this in the doc string in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ole Laursen <olau <at> iola.dk>, 19031 <at> debbugs.gnu.org
Subject: Re: bug#19031: 24.4; find-file in icomplete-mode shows completions
 with no input
Date: Fri, 04 Dec 2020 13:37:17 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Ole Laursen <olau <at> iola.dk> writes:
>
>> Run emacs -Q, evaluate
>>
>>   (icomplete-mode 1)
>>
>> then press C-x C-f and wait a second. There's now completions in the
>> minibuffer despite icomplete-show-matches-on-no-input being nil. Perhaps
>> icomplete is confused by the current working dir being present in C-x
>> C-f.
>
> I think the icomplete-show-matches-on-no-input doc string is just
> unclear here.  It seems like the point of the variable is that you can
> set it to non-nil to force icomplete to wait until we have completions
> before displaying the prompt?  When it's the default nil value, it'll
> still show all the matches, but they may arrive asynchronously.

When the `icomplete-show-matches-on-no-input` variable is nil,
completions will be not shown while minibuffer is empty:

1. emacs -Q
2. M-x icomplete-mode
3. M-x
   => No completions
4. f
   => Completions
5. C-/
   => No completions

With the 'find-file' function, minibuffer already contains the text --
the default directory.  Once the minibuffer will become empty
completions will be hidden:

1. emacs -Q
2. M-x icomplete-mode
3. C-x C-f
   => Completions 
4. C-x h C-w
   => No completions

> I've now clarified this in the doc string in Emacs 28.

Maybe it would be better to replace the text

"When non-nil, show completions when first prompting for input."

with something like

"When non-nil, show completions when minibuffer is empty."

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: Ole Laursen <olau <at> iola.dk>, 19031 <at> debbugs.gnu.org
Subject: Re: bug#19031: 24.4; find-file in icomplete-mode shows completions
 with no input
Date: Sun, 06 Dec 2020 13:46:29 +0100

Andrii Kolomoiets <andreyk.mad <at> gmail.com> writes:

> When the `icomplete-show-matches-on-no-input` variable is nil,
> completions will be not shown while minibuffer is empty:
>
> 1. emacs -Q
> 2. M-x icomplete-mode
> 3. M-x
>    => No completions
> 4. f
>    => Completions
> 5. C-/
>    => No completions

Ah, I was misunderstanding what I was seeing...  I've now reverted my
patch and reformulated as you suggest:

> Maybe it would be better to replace the text
>
> "When non-nil, show completions when first prompting for input."
>
> with something like
>
> "When non-nil, show completions when minibuffer is empty."

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Ole Laursen <olau <at> iola.dk>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 19031 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#19031: 24.4; find-file in icomplete-mode shows completions
 with no input
Date: Mon, 7 Dec 2020 12:43:38 +0100

Den søn. 6. dec. 2020 kl. 13.46 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> Ah, I was misunderstanding what I was seeing...  I've now reverted my
> patch and reformulated as you suggest:

I originally reported this because I found it jarring to get a bunch
of completions without having entered anything. In my home dir it
basically shows me garbage (dot files that I'm never interested in).

Would it not be possible to make a difference between the case where
find-file provides some default text (current dir) and where I have
entered some input? The variable literally says -on-no-input.

This is probably a wishlist thing - so I'm not going to complain if
you keep it closed. :)


Ole

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

From: Juri Linkov <juri <at> linkov.net>
To: Ole Laursen <olau <at> iola.dk>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 19031 <at> debbugs.gnu.org,
 Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#19031: 24.4; find-file in icomplete-mode shows completions
 with no input
Date: Tue, 08 Dec 2020 10:51:04 +0200

> I originally reported this because I found it jarring to get a bunch
> of completions without having entered anything. In my home dir it
> basically shows me garbage (dot files that I'm never interested in).
>
> Would it not be possible to make a difference between the case where
> find-file provides some default text (current dir) and where I have
> entered some input? The variable literally says -on-no-input.

I tried to handle this case with the following patch, but it doesn't work
because read-file-name-default resets `minibuffer-default' to nil,
so icomplete doesn't know what was initial input in the minibuffer.

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 676917b9da..47bd8f90a4 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -579,7 +579,10 @@ icomplete-exhibit
         (goto-char (point-max))
                                         ; Insert the match-status information:
         (when (and (or icomplete-show-matches-on-no-input
-                       (> (icomplete--field-end) (icomplete--field-beg)))
+                       (if (stringp minibuffer-default)
+                           (/= (icomplete--field-end) (+ (icomplete--field-beg)
+                                                         (length minibuffer-default)))
+                         (> (icomplete--field-end) (icomplete--field-beg))))
                    (or
                     ;; Don't bother with delay after certain number of chars:
                     (> (- (point) (icomplete--field-beg))

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

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Ole Laursen <olau <at> iola.dk>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 19031 <at> debbugs.gnu.org
Subject: Re: bug#19031: 24.4; find-file in icomplete-mode shows completions
 with no input
Date: Tue, 08 Dec 2020 12:43:21 +0200

Juri Linkov <juri <at> linkov.net> writes:

>> I originally reported this because I found it jarring to get a bunch
>> of completions without having entered anything. In my home dir it
>> basically shows me garbage (dot files that I'm never interested in).
>>
>> Would it not be possible to make a difference between the case where
>> find-file provides some default text (current dir) and where I have
>> entered some input? The variable literally says -on-no-input.
>
> I tried to handle this case with the following patch, but it doesn't work
> because read-file-name-default resets `minibuffer-default' to nil,
> so icomplete doesn't know what was initial input in the minibuffer.

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.

I was thinking about some method wich will allow to tell that minibuffer
is empty even if there are some user input.  From your patch I learned
about the 'minibuffer-default' variable and looks like it can be the
method I was thinking of.

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.

WDYT?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: Ole Laursen <olau <at> iola.dk>, 19031 <at> debbugs.gnu.org,
 Juri Linkov <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 14:29:05 +0100

Andrii Kolomoiets <andreyk.mad <at> gmail.com> writes:

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

Sounds like logical behaviour to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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.

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

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 18:16:10 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

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

Yes.  It's not about filtering out dotfiles but about to make icomplete
to not show completions until user starts typing filename.  Completions
(including dotfiles) will be shown when user will type e.g. ".e" or when
the 'icomplete-show-matches-on-no-input' variable is 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.

If there are no separator in the input, 'minibuffer-default' will be
empty string and completions will be shown.

Example of desired behavior:
1. emacs -Q
2. M-x icomplete-mode
3. C-x C-f
   minibuffer content: ~/
   minibuffer-default is "~/"
   no completions are shown
4. Type ".em"
   minibuffer content: ~/.em
   minibuffer-default is "~/"
   completions are shown
5. Type "acs.d/"
   minibuffer content: ~/.emacs.d/
   minibuffer-default is "~/.emacs.d/"
   no completions are shown

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

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

Den tir. 8. dec. 2020 kl. 17.16 skrev Andrii Kolomoiets <andreyk.mad <at> gmail.com>:
> Yes.  It's not about filtering out dotfiles but about to make icomplete
> to not show completions until user starts typing filename.  Completions
> (including dotfiles) will be shown when user will type e.g. ".e" or when
> the 'icomplete-show-matches-on-no-input' variable is t.

So conceptually chop the path up and consider each component of it a
separate completion task? I think that is a good match for how I'm
going about it.


Ole

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

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

>> 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.
>
> Yes.  It's not about filtering out dotfiles but about to make icomplete
> to not show completions until user starts typing filename.

To make icomplete to not show completions until user starts typing filename,
icomplete could remember the initial minibuffer content immediately after its
activation, then after the user edits the minibuffer, compare the new content
with the stored initial one.  So this doesn't require any changes
outside of icomplete.

> If there are no separator in the input, 'minibuffer-default' will be
> empty string and completions will be shown.
>
> Example of desired behavior:
> 1. emacs -Q
> 2. M-x icomplete-mode
> 3. C-x C-f
>    minibuffer content: ~/
>    minibuffer-default is "~/"
>    no completions are shown
> 4. Type ".em"
>    minibuffer content: ~/.em
>    minibuffer-default is "~/"
>    completions are shown
> 5. Type "acs.d/"
>    minibuffer content: ~/.emacs.d/
>    minibuffer-default is "~/.emacs.d/"
>    no completions are shown

I'm not sure if such special casing for directory separators is needed.
The option icomplete-show-matches-on-no-input is quite simple and it
should check if the user changed the initial content.

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

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

Juri Linkov <juri <at> linkov.net> writes:

>> Yes.  It's not about filtering out dotfiles but about to make icomplete
>> to not show completions until user starts typing filename.
>
> To make icomplete to not show completions until user starts typing filename,
> icomplete could remember the initial minibuffer content immediately after its
> activation, then after the user edits the minibuffer, compare the new content
> with the stored initial one.  So this doesn't require any changes
> outside of icomplete.

This may lead to unexpected behavior:

  (read-file-name "? " "~/" nil nil ".em")

Completions will be shown for minibuffer content like "~/.e" and
"~/.ema" but not for "~/.em".

Please read "until user starts typing filename" in my previous message
as "until input doesn't contains part of filename" ;)

> I'm not sure if such special casing for directory separators is needed.
> The option icomplete-show-matches-on-no-input is quite simple and it
> should check if the user changed the initial content.

Anyway the 'minibuffer-default' variable is not the right place to do
such thing.  It is used to provide default values which can be inserted
into the minibuffer with 'M-n':

1. emacs -Q
2. M-: (setq enable-recursive-minibuffers t)
3. C-x C-f
4. M-: (setq minibuffer-default "foo")
5. M-n

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

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

>> To make icomplete to not show completions until user starts typing filename,
>> icomplete could remember the initial minibuffer content immediately after its
>> activation, then after the user edits the minibuffer, compare the new content
>> with the stored initial one.  So this doesn't require any changes
>> outside of icomplete.
>
> This may lead to unexpected behavior:
>
>   (read-file-name "? " "~/" nil nil ".em")
>
> Completions will be shown for minibuffer content like "~/.e" and
> "~/.ema" but not for "~/.em".

Right, this behavior is described by the name of the option
icomplete-show-matches-on-no-input, i.e. with its default nil:
no input - no matches shown.  So the patch below implements this.

> Please read "until user starts typing filename" in my previous message
> as "until input doesn't contains part of filename" ;)

This is some new feature that can be implemented by a new option,
maybe something similar to icomplete-tidy-shadowed-file-names.

>> I'm not sure if such special casing for directory separators is needed.
>> The option icomplete-show-matches-on-no-input is quite simple and it
>> should check if the user changed the initial content.
>
> Anyway the 'minibuffer-default' variable is not the right place to do
> such thing.  It is used to provide default values which can be inserted
> into the minibuffer with 'M-n':
>
> 1. emacs -Q
> 2. M-: (setq enable-recursive-minibuffers t)
> 3. C-x C-f
> 4. M-: (setq minibuffer-default "foo")
> 5. M-n

I agree.

And here is the patch that implements what the name of
icomplete-show-matches-on-no-input suggests:

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 0fdacd0a3c..84a5f88234 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -146,6 +146,9 @@ icomplete-minibuffer-setup-hook
 (defvar icomplete-overlay (make-overlay (point-min) (point-min) nil t t)
   "Overlay used to display the list of completions.")
 
+(defvar icomplete-initial nil
+  "Initial input in the minibuffer.")
+
 (defun icomplete-pre-command-hook ()
  (let ((non-essential t))
    (icomplete-tidy)))
@@ -441,6 +444,7 @@ icomplete-minibuffer-setup
   "Run in minibuffer on activation to establish incremental completion.
 Usually run by inclusion in `minibuffer-setup-hook'."
   (when (and icomplete-mode (icomplete-simple-completing-p))
+    (setq-local icomplete-initial (minibuffer-contents))
     (setq-local completion-show-inline-help nil)
     (use-local-map (make-composed-keymap icomplete-minibuffer-map
     					 (current-local-map)))
@@ -579,7 +583,9 @@ icomplete-exhibit
         (goto-char (point-max))
                                         ; Insert the match-status information:
         (when (and (or icomplete-show-matches-on-no-input
-                       (> (icomplete--field-end) (icomplete--field-beg)))
+                       (if (stringp icomplete-initial)
+                           (not (equal icomplete-initial (minibuffer-contents)))
+                         (> (icomplete--field-end) (icomplete--field-beg))))
                    (or
                     ;; Don't bother with delay after certain number of chars:
                     (> (- (point) (icomplete--field-beg))

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

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

Juri Linkov <juri <at> linkov.net> writes:

>> Please read "until user starts typing filename" in my previous message
>> as "until input doesn't contains part of filename" ;)
>
> This is some new feature that can be implemented by a new option,
> maybe something similar to icomplete-tidy-shadowed-file-names.

Agree.

> And here is the patch that implements what the name of
> icomplete-show-matches-on-no-input suggests:

Looks great!

One thing left to do is to change the docstring of the
icomplete-show-matches-on-no-input variable.

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

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

>>> Please read "until user starts typing filename" in my previous message
>>> as "until input doesn't contains part of filename" ;)
>>
>> This is some new feature that can be implemented by a new option,
>> maybe something similar to icomplete-tidy-shadowed-file-names.
>
> Agree.

A new option could be implemented in a new feature request.

>> And here is the patch that implements what the name of
>> icomplete-show-matches-on-no-input suggests:
>
> Looks great!
>
> One thing left to do is to change the docstring of the
> icomplete-show-matches-on-no-input variable.

Now pushed to master with the docstring updates,
and used icomplete-initial-input in more places.

Previous Next

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