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 20:29:38 -0800 Message-ID: References: <65EEA895D8A0443A859A780AB233146E@us.oracle.com><625A327B282C4C279837A7542B76E5C8@us.oracle.com><87zjzk112u.fsf@gmail.com><20DF11E25EE542A1A334DA1FDB79F77B@us.oracle.com> <87bobz7ajl.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 1360048642 10618 80.91.229.3 (5 Feb 2013 07:17:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Feb 2013 07:17:22 +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 Tue Feb 05 08:17:42 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 1U2cme-0002uQ-D6 for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Feb 2013 08:17:36 +0100 Original-Received: from localhost ([::1]:50336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2cmL-0004Yb-Js for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Feb 2013 02:17:17 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2cmI-0004YD-5E for bug-gnu-emacs@gnu.org; Tue, 05 Feb 2013 02:17:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2cmC-0001WK-UV for bug-gnu-emacs@gnu.org; Tue, 05 Feb 2013 02:17:14 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59436) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2aAM-0001CR-TC for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 23:29:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U2aBS-0003BL-Or for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 23:31: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: Tue, 05 Feb 2013 04:31: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.136003865712217 (code B ref 13602); Tue, 05 Feb 2013 04:31:02 +0000 Original-Received: (at 13602) by debbugs.gnu.org; 5 Feb 2013 04:30:57 +0000 Original-Received: from localhost ([127.0.0.1]:36667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2aBN-0003Az-5e for submit@debbugs.gnu.org; Mon, 04 Feb 2013 23:30:57 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18025) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2aBK-0003Ar-V1 for 13602@debbugs.gnu.org; Mon, 04 Feb 2013 23:30:56 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r154TgF3020097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Feb 2013 04:29:43 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r154TfL7009934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 04:29:42 GMT Original-Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r154Tfgs015450; Mon, 4 Feb 2013 22:29:41 -0600 Original-Received: from dradamslap1 (/10.159.165.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Feb 2013 20:29:40 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87bobz7ajl.fsf@gmail.com> Thread-Index: Ac4DSXiIja2UfsbeTMGEDgDjprFcOQABG3/A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:70708 Archived-At: > >> 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. > > How can you argue for a case without supporting documents? > Why refuse the explicit call for evidence. It's not about me. It's not about any libraries I might use. I could as easily and as honestly have answered your question with "No, and it is irrelevant." I don't particularly or personally need any of the keys you propose to have Icomplete bind, for any other purpose. For my own use, the problem does not exist. I've already added a mode to separate the cycling behavior from the show-completions behavior - au choix. I sent the code for that, as an example. That's reasonable, IMO. It's about Emacs users generally, and Icomplete generally. Icomplete has played a useful role for a long time, usable in combination with emacs -Q and with any other code that binds any keys in the minibuffer. That's pretty darn useful. Icomplete's lack of key bindings is an important feature, one that lets it fit in. It is apparently this point that you are not getting. You appear to be focused on your new feature and not appreciating Icomplete for the simplicity it offers. That feature of getting along with others is now thrown to the wind because you want to add another feature that compromises it. All I am suggesting is that we keep that useful feature and provide your bells and whistles as an easy-to-use-easy-to-refuse option. What's wrong with that? It's about keeping Icomplete so that it plays well with emacs -Q and with any minibuffer key bindings that any user might have, bindings existing today or tomorrow, coming from anywhere. That should be the default. If Icomplete is now going to provide a mode where it adds its own bindings, which obviously could conflict with other bindings, then that mode should be optional, and preferably not be the default Icomplete behavior. Until now, Icomplete has not had a behavior wrt keys. You want to give it an Ido-like behavior. I say fine, make that an option, so the good ol' Icomplete, which imposes no key behavior, is still there as the default. I would have said the same thing if the proposal were to give Icomplete a Viper-like key behavior, or an Icicles-like key behavior, or an mcomplete.el key behavior, or a minibuffer-complete-cycle.el key behavior, or a cycle-mini.el key behavior, or a Helm key behavior, or a timid.el key behavior, or Suzy Creamcheese's custom minibuffer key behavior, or any other minibuffer key behavior. The point is to keep Icomplete simple and informational, having nothing to do with keys, so that it plays well with any completion minibuffer - by default.