[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: Stephen Leake
Subject: Re: bug#17545: 24.4.50; icomplete conflicts with minibuffer default
Date: Mon, 18 May 2015 14:41:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt)

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."
  ;; we _don't_ want the default specified by read-buffer! (reopen bug#17545)
  (let ((minibuffer-default nil))

-- Stephe

reply via email to

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