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 09:40:50 -0800 Message-ID: <20DF11E25EE542A1A334DA1FDB79F77B@us.oracle.com> References: <65EEA895D8A0443A859A780AB233146E@us.oracle.com><625A327B282C4C279837A7542B76E5C8@us.oracle.com> <87zjzk112u.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 1359999734 16947 80.91.229.3 (4 Feb 2013 17:42:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Feb 2013 17:42:14 +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 18:42:32 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 1U2Q3l-00016S-AW for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 18:42:25 +0100 Original-Received: from localhost ([::1]:60124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Q3S-0001em-HF for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 12:42:06 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Q3O-0001da-0d for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 12:42:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2Q3J-0005nx-2y for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 12:42:01 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Q3I-0005nf-Va for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 12:41:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U2Q4M-0003GV-6k for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 12:43: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 17:43: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.135999972312480 (code B ref 13602); Mon, 04 Feb 2013 17:43:02 +0000 Original-Received: (at 13602) by debbugs.gnu.org; 4 Feb 2013 17:42:03 +0000 Original-Received: from localhost ([127.0.0.1]:36268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2Q3O-0003FF-Lf for submit@debbugs.gnu.org; Mon, 04 Feb 2013 12:42:03 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:44713) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2Q3L-0003En-WC for 13602@debbugs.gnu.org; Mon, 04 Feb 2013 12:42:00 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r14Heqfo019931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Feb 2013 17:40:53 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r14Hepgh028691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 17:40:52 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r14Hepdk026374; Mon, 4 Feb 2013 11:40:51 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Feb 2013 09:40:51 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87zjzk112u.fsf@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4C9uGSIPzQ+I2uRV2p1y19KHBrOwABWuUw X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:70692 Archived-At: > > And do not have Icomplete trample minibuffer bindings by > > default. Let users opt in for that. > > Does Ido-like Icomplete mode interfere with any of your (existing?) > libraries? Yes, but it is irrelevant. I am not arguing wrt any other libraries. The argument is general. It is wrt emacs -Q and its normal, default minibuffer behavior. And it is general in that it is also wrt nearly any minibuffer behavior (not just emacs -Q), from nearly any package, whether it be distributed by Emacs (e.g. Ido, Viper) or not. There is nothing in my argument that relates specifically to any given package. Until now, Icomplete has simply aided users passively, by showing the possibile completions. It has not in any way changed the behavior of the user's interaction with the minibuffer (e.g. keys). That should continue to be the default behavior: let Icomplete inform about completions but not change the current minibuffer interaction (whatever that might be, emacs -Q or otherwise). Let Icomplete also offer an additional mode, like CUA does with CUA mode instead of CUA selection mode, whereby it binds some cycling keys. So much the better - I'm glad you provided this feature. > Note that I have no opinion on whether cycling should be opt-in or > opt-out, by default. I do. It should be opt-in, so that Icomplete preserves, by default, whatever minibuffer behavior is already present and preferred by the user. There are many different minibuffer behaviors besides emacs -Q and Ido. Some, like Viper and Ido, are very different from emacs -Q. Some are more similar to emacs -Q. The point is that a user's preferred minibuffer interaction should not be thrown to the wind just because s?he turns on Icomplete mode. And whether opt-in or opt-out, it should be trivial and clear for a user how to toggle to the other behavior. The code I sent lets you do that using a command/key. No fiddling with keymaps by users, etc. If users want to change which keys are used for Icomplete cycling, _then_ they can fiddle with the bindings.