From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode Date: Mon, 4 Feb 2013 08:02:30 -0800 Message-ID: <7AA8345D494A4766B6E958E7EC4804C3@us.oracle.com> References: <65EEA895D8A0443A859A780AB233146E@us.oracle.com> <87lib4e5m4.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1359996099 10817 80.91.229.3 (4 Feb 2013 16:41:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Feb 2013 16:41:39 +0000 (UTC) Cc: 13602@debbugs.gnu.org To: "'Jambunathan K'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 04 17:41:59 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 1U2P7F-0001tX-Cd for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 17:41:57 +0100 Original-Received: from localhost ([::1]:60743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2P6w-0002M4-UF for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 11:41:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2OVX-0005zV-3A for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 11:03:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2OVV-0001w0-Fr for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 11:02:59 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2OVV-0001vw-Cn for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 11:02:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U2OWY-0000wH-7U for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 11:04:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Feb 2013 16:04:02 +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.13599938353597 (code B ref 13602); Mon, 04 Feb 2013 16:04:02 +0000 Original-Received: (at 13602) by debbugs.gnu.org; 4 Feb 2013 16:03:55 +0000 Original-Received: from localhost ([127.0.0.1]:36175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2OWP-0000vy-L3 for submit@debbugs.gnu.org; Mon, 04 Feb 2013 11:03:55 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:51406) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2OWM-0000vn-Mt for 13602@debbugs.gnu.org; Mon, 04 Feb 2013 11:03:52 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r14G2i1K030066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Feb 2013 16:02:44 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r14G2hcQ006840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 16:02:43 GMT Original-Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r14G2hY8008173; Mon, 4 Feb 2013 10:02:43 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Feb 2013 08:02:43 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87lib4e5m4.fsf@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4CwkjhZqMXzzTtRwChXV/HqLBJSgAJ+KMA X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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:70684 Archived-At: > You don't use ido-mode, do you? No, thank you. And it is not the default behavior for Emacs either. You won't even find it described in the Emacs manual, where the minibuffer is described in detail. The real question is "Have you used Emacs (and Icomplete) without Ido mode?" That's the use case I'm concerned about. If you wear Ido-colored glasses when thinking about this then you will likely not see clearly that a user can want these keys to be left alone, to be used otherwise, as before. > These bindings mimic the behaviour of ido-mode. Yes, I know. (Actually, it is Ido that mimicked Icomplete and IswitchB.) If you want Ido then you do not really need Icomplete anyway. Regardless, these keys should be optional for Icomplete. Icomplete is not Ido. > As a user, I can't be too concerned with the > backend library facilitating completions. In changing Icomplete for all users you are acting as an Emacs developer, not just as one user. And the concern for users is not dependent on any backend libraries. `emacs -Q' does not put you in Ido mode, and it lets you use all kinds of keys in the minibuffer, including C-s and C-r. Icomplete should continue to be compatible with this, if a user so prefers. Users can prefer not to have Icomplete bind such keys, to keep Icomplete for what it was originally designed (informative help), and to allow those keys to be used otherwise in the minibuffer, just as before. The minibuffer is a buffer where you can _edit_ your input. That Ido restricts the minibuffer behavior, removing this editing possibility (well, restricting it modally), is a specialty of Ido - it is not the normal behavior of the Emacs minibuffer. The minibuffer is much bigger in behavior and possibilities than what Ido allows for. Nothing wrong with Ido doing what it does to the minibuffer, for its own purposes. But that's not the Emacs minibuffer, in general. And Icomplete has always been compatible with the general, emacs -Q, minibuffer. This should continue, at least as the default behavior. These key bindings should be optional, in a separate mode, just as for CUA mode and CUA Selection mode. Let me be clear. I have nothing against Ido or against the keys you defined for use with Icomplete. I believe that both can be useful, and I applaud your addition of the keys to Icomplete. The point is that they should be optional. Turning on Icomplete mode should not suddenly remove the possibility of using these or any other keys in the minibuffer for their normal behavior. > Does playing around with `icomplete-minibuffer-setup-hook' > help with getting the behaviour you want? Users should not need to so play around. > 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. I seriously doubt that I have a better understanding of keymaps than you do. What should be done is to put the binding of such keys into a separate, optional mode. Keep Icomplete mode for what it was intended (information display), and add a mode on top of it that additionally provides the Ido-like keys. Simple, friendly to users, no change of the minibuffer keys unless you want it. Here is what I do, in case it helps. (The only reason for the mode var defvar and the eval here is so the code will work also with older Emacs versions. If integrated with icomplete.el such code could be greatly simplified.) (defvar icompletep-ORIG-icomplete-minibuffer-map) (defvar icompletep-cycling-mode nil) (when (boundp 'icomplete-minibuffer-map) ; Emacs 24.4+ (setq icompletep-ORIG-icomplete-minibuffer-map icomplete-minibuffer-map ; Save it and wipe it out. icomplete-minibuffer-map nil) (eval '(define-minor-mode icompletep-cycling-mode "Icomplete, with cycling keys enabled if on, disabled if off. If off then the cycling keys of Icomplete mode are free for their normal minibuffer uses. The default Icomplete-mode cycling keys are: M-TAB\t- complete to exact match, repeat to cycle C-j\t- complete to first match and exit minibuffer C-s\t- cycle first entry to end C-r\t- cycle last entry to start If you want Icomplete cycling behavior but do not want to use these keys for it, customize the bindings in `icomplete-minibuffer-map'. Turning this mode on also turns on Icomplete mode. Turning it off does not turn Icomplete mode on or off." nil nil nil (when icompletep-cycling-mode (icomplete-mode 99)) (setq icomplete-minibuffer-map (and icompletep-cycling-mode icompletep-ORIG-icomplete-minibuffer-map)))) (icompletep-cycling-mode -99)) A user wanting the behavior you want need only turn on `icompletep-cycling-mode' instead of `icomplete-mode'. What's more, a user can bind the mode to a key, to easily toggle the cycling keys on/off, without leaving Icomplete mode. > > 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. Why? Why not return Icomplete to what it was and give Ido-oriented users an easy choice to get the behavior you like? It is simple to do that. And I never said that you were "hijacking" these keys to "useless ends". The ends you propose are useful. But they should be optional, as these keys can also be useful with their usual (or with other) bindings. I am in favor of the addition of the possibility of cycling to Icomplete mode. But it should be optional; that's all. The model of CUA mode and CUA selection modes should serve here: Use another mode if you want the cycling keys in addition to the information behavior of Icomplete. Key "hijacking" off by default, for Icomplete mode. > > (setq-default cua-enable-cua-keys nil) > > ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^