From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.bugs Subject: bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode Date: Mon, 04 Feb 2013 15:57:31 +0530 Message-ID: <87lib4e5m4.fsf@gmail.com> References: <65EEA895D8A0443A859A780AB233146E@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1359973684 18391 80.91.229.3 (4 Feb 2013 10:28:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Feb 2013 10:28:04 +0000 (UTC) Cc: 13602@debbugs.gnu.org To: "Drew Adams" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 04 11:28:24 2013 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 1U2JHi-00068f-3r for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 11:28:22 +0100 Original-Received: from localhost ([::1]:57619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2JHP-0002jA-Fg for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 05:28:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2JHM-0002j0-2W for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 05:28:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2JHK-0005rQ-B8 for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 05:27:59 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2JHK-0005rL-7M for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 05:27:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U2JIL-0007qt-VH for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 05:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jambunathan K Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Feb 2013 10:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13602 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13602-submit@debbugs.gnu.org id=B13602.135997373830172 (code B ref 13602); Mon, 04 Feb 2013 10:29:01 +0000 Original-Received: (at 13602) by debbugs.gnu.org; 4 Feb 2013 10:28:58 +0000 Original-Received: from localhost ([127.0.0.1]:35226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2JIH-0007qX-55 for submit@debbugs.gnu.org; Mon, 04 Feb 2013 05:28:58 -0500 Original-Received: from mail-pa0-f44.google.com ([209.85.220.44]:39754) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2JIE-0007qN-8X for 13602@debbugs.gnu.org; Mon, 04 Feb 2013 05:28:55 -0500 Original-Received: by mail-pa0-f44.google.com with SMTP id kp1so493270pab.31 for <13602@debbugs.gnu.org>; Mon, 04 Feb 2013 02:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=tLrtyYVqRylOG8R/XO9YREbwtfiXoMCgtK6a5S4RdaU=; b=SRfIttZNT6pJ0K3W47ocnJEl5fymT08kt5DHMgaJPgGDSYHtNzbRoTaHCp55JSTjRY B9QKH0lqpn7uXsVoaw2PHIu7Dx9B5SBFfaFi4KnuDSCG0Dq1ci5oHahA88iKMvyH0vQO /ynEVTbuXw7rCd7Rgv10/eloCU5WkaOQ0AyxZdGY70LWf0DMakbi+HohFuLc1q46cQlk sYjvZna1ac1O87hGG8vVw4XGdsIIRaAnUy/TW24T7A1gHQZ1np0tNgNIwPxl4QXbYnO+ tOjohh89FvJ1HxcASbtDSCqmg8nvb4nTlKNF3zqeVah1gtg+TKpb7uV1mkFa0i5vzmV0 i44A== X-Received: by 10.66.72.97 with SMTP id c1mr51397825pav.48.1359973669235; Mon, 04 Feb 2013 02:27:49 -0800 (PST) Original-Received: from debian-6.05 ([115.241.71.156]) by mx.google.com with ESMTPS id d1sm20277108pav.6.2013.02.04.02.27.44 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Mon, 04 Feb 2013 02:27:48 -0800 (PST) In-Reply-To: <65EEA895D8A0443A859A780AB233146E@us.oracle.com> (Drew Adams's message of "Thu, 31 Jan 2013 11:41:44 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:70668 Archived-At: > These Icomplete keybindings are inappropriate: > > (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-s] 'icomplete-forward-completions) > (define-key map [?\C-r] 'icomplete-backward-completions) > map)) > > It is not kosher to bind such keys in the minibuffer in a general mode. > Let users bind them if they like. > In particular: C-s and C-r are used to search minibuffer text (e.g. move > the cursor). M-TAB is useful in the minibuffer to complete names. And > users and applications can reasonably bind C-j to be self-inserting in > the minibuffer, just as some do for SPC. You don't use ido-mode, do you? These bindings mimic the behaviour of ido-mode. As a user, I can't be too concerned with the backend library facilitating completions. > `icomplete-mode-map' should not even be unconditionally imposed as part > of the local map when Icomplete mode is turned on. I don't see any `icomplete-mode-map'. Does playing around with `icomplete-minibuffer-setup-hook' help with getting the behaviour you want? In `icomplete-minibuffer-setup', should setting up of composed map be delayed until after the `icomplete-minibuffer-setup' had a chance to run? I am posing this as a question, for you have better understanding of keymaps than I do. > You have made it difficult for users to get the normal, traditional > Icomplete behavior without your recent additions for cycling. > Misguided. Please let users more easily choose whether they want that. May be we should wait until one another user complains about hijacking of search keys to useless ends. > I propose that you create a separate mode for using > `icomplete-mode-map', analogous to the separation between `cua-mode' and > `cua-selection-mode'. That is clean and simple for you to do. > > Users turning on Icomplete mode would not get these key bindings. Users > turning on the new Icomplet-With-Cycling mode (or whatever name you > like) would get the current behavior you have defined: Icomplete plus > your keybindings. > > This approach would give users more contol - an easy way to get your new > cycling feature or to do without it. If they choose to use it, they can > always change the key bindings. Even in that case, my suggestion would > be that you pick different default bindings. But at least with this > approach no bindings would not be imposed on regular Icomplete users. > > (defun cua-selection-mode (arg) > "Enable CUA selection mode without the C-z/C-x/C-c/C-v bindings." > (interactive "P") > (setq-default cua-enable-cua-keys nil) > ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > (if (not (called-interactively-p 'any)) > (cua-mode arg) > ;; Use call-interactive to turn a nil prefix arg into `toggle'. > (call-interactively 'cua-mode) > (customize-mark-as-set 'cua-enable-cua-keys))) > > In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) > of 2013-01-25 on ODIEONE > Bzr revision: 111604 eliz@gnu.org-20130125143821-1ykj7ia1qjojjjnp > Windowing system distributor `Microsoft Corp.', version 5.1.2600 > Configured using: > `configure --with-gcc (4.7) --no-opt --enable-checking --cflags > -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib' --