[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: bug#17545: 24.4.50; icomplete conflicts with minibuffer default
Date: Sun, 17 May 2015 04:07:07 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]