GNU bug report logs - #17545
24.4.50; icomplete conflicts with minibuffer default

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#17545: closed (24.4.50; icomplete conflicts with minibuffer
 default)
Date: Sun, 01 Jun 2014 02:26:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 31 May 2014 22:25:26 -0400
with message-id <jwvr439icyp.fsf-monnier+emacsbugs <at> gnu.org>
and subject line Re: bug#17545: 24.4.50; icomplete conflicts with minibuffer default
has caused the debbugs.gnu.org bug report #17545,
regarding 24.4.50; icomplete conflicts with minibuffer default
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
17545: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17545
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Dan McKinley <mcfunley <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; icomplete conflicts with minibuffer default
Date: Wed, 21 May 2014 08:40:03 -0700

[Message part 3 (text/plain, inline)]

When completing in the minibuffer using icomplete-mode, an invisible
completion can circumvent the minibuffer's default selection.

For example, say you have icomplete enabled, and you try to kill the
current buffer. The minibuffer will show a confirmation message like,
"Kill buffer (default: foo)". If you type C-j to trigger icomplete
without having actually typed any characters, icomplete will terminate
an unrelated buffer and won't even tell you which it was. It will
terminate whatever buffer it decides is the completion of nothing at
that time.

This is confusing because the minibuffer prompt suggests a completely
different default. Here's a function that fixes the behavior:

(defun icomplete-complete-or-default ()
  (interactive)
  (let* ((start (minibuffer-prompt-end))
         (end (point-max))
         (phrase (buffer-substring start end)))

    (if (zerop (length phrase))
        ; Select the minibuffer's default if there's no text after
        ; the prompt.
        (minibuffer-complete-and-exit)

      ; Select icomplete's default completion if the user has typed
      ; something.
      (minibuffer-force-complete-and-exit))
  ))

Then remapping C-j to call that in the icomplete keymap fixes the bug:

 (defvar icomplete-minibuffer-map
   (let ((map (make-sparse-keymap)))
     (define-key map [?\M-\t] 'minibuffer-force-complete)
-    (define-key map [?\C-j]  'minibuffer-force-complete-and-exit)
+    (define-key map [?\C-j]  'icomplete-complete-or-default)
     (define-key map [?\C-.]  'icomplete-forward-completions)
     (define-key map [?\C-,]  'icomplete-backward-completions)
     map)
   "Keymap used by `icomplete-mode' in the minibuffer.")

I came across this trying to remap icomplete to <return> instead of C-j
so that the keys are more like the (apparently dead) iswitchb. That
doesn't seem like an unreasonable thing to do, although I don't know how
many people used iswitchb.

[Message part 4 (text/html, inline)]

[Message part 5 (message/rfc822, inline)]

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dan McKinley <mcfunley <at> gmail.com>
Cc: 17545-done <at> debbugs.gnu.org
Subject: Re: bug#17545: 24.4.50; icomplete conflicts with minibuffer default
Date: Sat, 31 May 2014 22:25:26 -0400

>> This is confusing because the minibuffer prompt suggests a completely
>> different default. Here's a function that fixes the behavior:
> I think a better fix is to change icomplete such that if the default is
> among the possible completions, then it appears first.

In the end I installed patch following the same idea as yours (but
folded into minibuffer-force-complete-and-exit).  Thank you.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.