RE: [Emacs-diffs] /srv/bzr/emacs/trunk r108646: * minibuffer.el(read-file-name-default): Bind `non-essential' to `t'.

[Drew Adams]

> > Here's a recipe to reproduce the problem (revert the patch in
> > minibuffer.el first):
> > emacs -Q -l icomplete -f icomplete-mode
> > C-x C-f /ssh:localhost:/ <TAB>
> 
> I don't see any problem here.  Tramp requests a password, as expected
> and as it should (since the user hit TAB, she clearly wants 
> completion).

If I can chime in about the use case, though not about the implementation/fix -

I think that for most users most of the time, the completions shown by Icomplete
act mainly as background help.  They are not "essential", and most users (or at
least some users) would not want to be interrupted when entering a file name
just to provide some password because their minibuffer input so far was
recognized by Tramp/ange-ftp as possibly corresponding to a remote file.

A user who does want Tramp to prompt for a password need only hit TAB to cause
that.  IOW, I think there is a difference in how much a user is actively
requesting completion between hitting TAB and just letting Icomplete precomplete
the current input.

This is only about Icomplete preventing _its_ preparation of completion
suggestions from prompting the user to access a remote file system.

And if we think that some users do want Tramp to kick in during Icomplete, then
we can provide a user option (e.g. in icomplete.el) to control the behavior.

In sum, I think that most of the time an Icomplete user does not want Icomplete
to be so eager/assertive/aggressive.  (It is a bit like Eldoc.)

Again, I am not speaking about the implementation or about things other than
Icomplete.

If I had to guess about Ido, for instance, it would be that users of Ido might
typically want Tramp to interrupt for a password.

But users should in general be able to ignore Icomplete's suggestions - it
should be possible to treat Icomplete as background noise.  It would be OK for
that to be controlled by a user option.