Re: bug#17545: 24.4.50; icomplete conflicts with minibuffer default

[Dmitry Gutov]

On 05/16/2015 05:23 PM, Stefan Monnier wrote:
> > It seems the easiest way to resolve this is to always make the default
> > the first item, even when it's not in the collection passed to
> > `completing-read'.
>
> But if the user hit C-., that should change the default.

Why? Suppose I've pressed C-. a few times, didn't find what I wanted, 
typed a few chars (didn't find what I wanted there either), erased them, 
then resigned to my fate and pressed RET. Why would the end selection be 
the result of those random C-. presses, rather than the default 
specified by the caller?

On the other hand, we could even call the complaint that started this 
bug "working as intended". Because C-j is bound to 
minibuffer-force-complete-and-exit, and its docstring promises it will 
use the first of the matches. The default isn't even mentioned (the 
current implementation is against the spec in this regard).

But if we wanted to keep that behavior, we could devise a more direct 
way for a completing-read-function to tell minibuffer that some input 
has been performed. (eq (minibuffer-prompt-end) (point-max)) apparently 
doesn't cut it.

Or rather whether any completions are visible. Because if 
icomplete-show-matches-on-no-input is non-nil, it would be harder to 
justify using the default instead of the first completion in 
minibuffer-force-complete-and-exit, even if the user hasn't made any 
other input.