GNU bug report logs -
#17545
24.4.50; icomplete conflicts with minibuffer default
Previous Next
Reported by: Dan McKinley <mcfunley <at> gmail.com>
Date: Wed, 21 May 2014 16:08:02 UTC
Severity: normal
Found in version 24.4.50
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17545 in the body.
You can then email your comments to 17545 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17545
; Package
emacs
.
(Wed, 21 May 2014 16:08:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dan McKinley <mcfunley <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 21 May 2014 16:08:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (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 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17545
; Package
emacs
.
(Wed, 21 May 2014 17:54:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 17545 <at> debbugs.gnu.org (full text, mbox):
> "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.
Good point.
> 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.
Stefan
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
You have taken responsibility.
(Sun, 01 Jun 2014 02:26:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dan McKinley <mcfunley <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 01 Jun 2014 02:26:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 17545-done <at> debbugs.gnu.org (full text, mbox):
>> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 29 Jun 2014 11:24:04 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Stefan Monnier <monnier <at> iro.umontreal.ca>
to
control <at> debbugs.gnu.org
.
(Sun, 17 May 2015 02:01:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 14 Jun 2015 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 11 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.