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

[Stephen Leake]

Slawomir Nowaczyk <address@hidden> writes:

> On Sun, 17 May 2015 04:07:07 +0300
> Dmitry Gutov <address@hidden> wrote:
>
>> 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?
>
> How is emacs to know if the user has "resigned to his fate" or "found
> the item he wants"?

It needs two different key bindings: C-ret => use the default, ret =>
use current completed selection.

Also need a third key M-ret => use the current minibuffer input, without
completion (useful for renaming files to a non-existing name). Although
this can be combined with C-ret; if input, use that with no completion;
if no input, use the default.

I have a workaround to get ret:

(defun sal-icomplete-force-and-exit ()
  "Select the current completion."
  (interactive)
  ;; we _don't_ want the default specified by read-buffer! (reopen bug#17545)
  (let ((minibuffer-default nil))
    (minibuffer-force-complete-and-exit)))

-- 
-- Stephe