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

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

[Ole Laursen]

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

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

[Lars Ingebrigtsen]

Ole Laursen <olau@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

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

[Andrii Kolomoiets]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ole Laursen <olau@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."

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

[Lars Ingebrigtsen]

Andrii Kolomoiets <andreyk.mad@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

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

[Ole Laursen]

Den søn. 6. dec. 2020 kl. 13.46 skrev Lars Ingebrigtsen <larsi@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

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

[Juri Linkov]

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

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

[Andrii Kolomoiets]

Juri Linkov <juri@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?

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

[Lars Ingebrigtsen]

Andrii Kolomoiets <andreyk.mad@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

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

[Eli Zaretskii]

> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> Date: Tue, 08 Dec 2020 12:43:21 +0200
> Cc: Ole Laursen <olau@iola.dk>, Lars Ingebrigtsen <larsi@gnus.org>,
>  19031@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.

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

[Andrii Kolomoiets]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
>> Date: Tue, 08 Dec 2020 12:43:21 +0200
>> Cc: Ole Laursen <olau@iola.dk>, Lars Ingebrigtsen <larsi@gnus.org>,
>>  19031@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

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

[Ole Laursen]

Den tir. 8. dec. 2020 kl. 17.16 skrev Andrii Kolomoiets <andreyk.mad@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

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

[Juri Linkov]

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

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

[Andrii Kolomoiets]

Juri Linkov <juri@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

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

[Juri Linkov]

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

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

[Andrii Kolomoiets]

Juri Linkov <juri@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.

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

[Juri Linkov]

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