emacs-devel
[Top][All Lists]
Advanced

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

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


From: Slawomir Nowaczyk
Subject: Re: bug#17545: 24.4.50; icomplete conflicts with minibuffer default
Date: Mon, 18 May 2015 10:51:15 +0200

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"?

> 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).

Current behaviour definitely doesn't agree with the spec. Whether it's
"working as intended" I don't know -- but I definitely don't like it.

> 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.

I agree.

> 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.

FWIW, my current workaround is:
  (define-key icomplete-minibuffer-map (kbd "C-.") (lambda () "" (interactive) 
(progn (setq minibuffer-default nil) (icomplete-forward-completions))))
This is very ugly, but does what I want it to do.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( address@hidden )

A hundred thousand lemmings can't be wrong.  -- famous last words




reply via email to

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