From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan McKinley Newsgroups: gmane.emacs.bugs Subject: bug#17545: 24.4.50; icomplete conflicts with minibuffer default Date: Wed, 21 May 2014 08:40:03 -0700 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01538dfa6434b604f9eacfa1 X-Trace: ger.gmane.org 1400688497 8374 80.91.229.3 (21 May 2014 16:08:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 May 2014 16:08:17 +0000 (UTC) To: 17545@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 21 18:08:10 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wn93p-0003Eu-ST for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 May 2014 18:08:10 +0200 Original-Received: from localhost ([::1]:60719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn93p-00084g-DS for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 May 2014 12:08:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn93k-00082M-Tf for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 12:08:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wn93i-0003Ow-Vv for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 12:08:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn93i-0003Op-Se for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 12:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Wn93i-0001AN-9x for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 12:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dan McKinley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 May 2014 16:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 17545 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.14006884624444 (code B ref -1); Wed, 21 May 2014 16:08:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 21 May 2014 16:07:42 +0000 Original-Received: from localhost ([127.0.0.1]:55507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wn93M-00019b-If for submit@debbugs.gnu.org; Wed, 21 May 2014 12:07:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38629) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wn8cu-0007ZE-1q for submit@debbugs.gnu.org; Wed, 21 May 2014 11:40:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wn8cn-0001N2-MJ for submit@debbugs.gnu.org; Wed, 21 May 2014 11:40:14 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:35086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn8cn-0001Mx-KK for submit@debbugs.gnu.org; Wed, 21 May 2014 11:40:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn8cj-00035Z-La for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 11:40:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wn8cf-0001CO-Or for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 11:40:09 -0400 Original-Received: from mail-ob0-x22a.google.com ([2607:f8b0:4003:c01::22a]:48052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn8cf-00017o-6O for bug-gnu-emacs@gnu.org; Wed, 21 May 2014 11:40:05 -0400 Original-Received: by mail-ob0-f170.google.com with SMTP id uy5so2330752obc.15 for ; Wed, 21 May 2014 08:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DkkYwCwBEvUEJxANVz2Vf0JRI7MsiLR50u7HtG3eHRE=; b=AOyYvH0eEfJ6lvKmbjcxSB6RPNei2ymD5ai0Dg7J6avZKcJjOZ7Bp04CFJ8LKTiOBm aJKuZV+vNgIEx+RQ9D9eHzwXtbBCM4BFCFuf8GXhuxic/qP2ptu0nLfQIMMH/K/l4ntL ZgDpAgRKce70m3tZi4oeQmisr7mWpc0iDcB5QvLZwu7OkPcV1vBz75S+fX5exVHNqzau panJr3rv/VZmT+TcptuZGnI/aH22c3bgD94O9j8VOUk9LVJMDWMCJY+O5v/C7SsGlP1/ WoC6w5qnKiQ/Ex2DGJ0WMJZCmR2iipCDsfHA8fcE3BozFEhVjWeGmQyFEbsSRtX9ugtZ awoA== X-Received: by 10.182.99.198 with SMTP id es6mr20026236obb.69.1400686803954; Wed, 21 May 2014 08:40:03 -0700 (PDT) Original-Received: by 10.76.19.115 with HTTP; Wed, 21 May 2014 08:40:03 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Mailman-Approved-At: Wed, 21 May 2014 12:07:39 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:89327 Archived-At: --089e01538dfa6434b604f9eacfa1 Content-Type: text/plain; charset=UTF-8 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 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. --089e01538dfa6434b604f9eacfa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When completing in the minibuffer using icomplete-mod= e, an invisible
completion can circumvent the minibuffer's de= fault selection.

For example, say you have icomple= te enabled, and you try to kill the
current buffer. The minibuffer will show a confirmation message like,<= /div>
"Kill buffer (default: foo)". If you type C-j to trigge= r icomplete
without having actually typed any characters, icomple= te will terminate
an unrelated buffer and won't even tell you which it was. It will<= /div>
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 ()
=C2= =A0 (interactive)
=C2=A0 (let* ((start (minibuffer-prompt-end))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(end (point-max))
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(phrase (buffer-substring start end)))
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 (if (zerop (length = phrase))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; Select the minibuffer'= s default if there's no text after
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; the prompt.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 (minibuffer-complete-and-exit)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 ; Select icomplete's defaul= t completion if the user has typed
=C2=A0 =C2=A0 =C2=A0 ; somethi= ng.
=C2=A0 =C2=A0 =C2=A0 (minibuffer-force-complete-and-exit))
=C2=A0 ))

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

=C2=A0(defvar = icomplete-minibuffer-map
=C2=A0 =C2=A0(let ((map (make-sparse-key= map)))
=C2=A0 =C2=A0 =C2=A0(define-key map [?\M-\t] 'minibuffer-force-complete= )
- =C2=A0 =C2=A0(define-key map [?\C-j] =C2=A0'minibuffer-fo= rce-complete-and-exit)
+ =C2=A0 =C2=A0(define-key map [?\C-j] =C2= =A0'icomplete-complete-or-default)
=C2=A0 =C2=A0 =C2=A0(define-key map [?\C-.] =C2=A0'icomplete-forwa= rd-completions)
=C2=A0 =C2=A0 =C2=A0(define-key map [?\C-,] =C2= =A0'icomplete-backward-completions)
=C2=A0 =C2=A0 =C2=A0map)<= /div>
=C2=A0 =C2=A0"Keymap used by `icomplete-mode' in the min= ibuffer.")

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

--089e01538dfa6434b604f9eacfa1--