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:16:44 -0800 Message-ID: <7C3C252294774DB79419E50757D7D7EB@us.oracle.com> References: <65EEA895D8A0443A859A780AB233146E@us.oracle.com> <87halsxr3q.fsf@yandex.ru> 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 1359994684 27149 80.91.229.3 (4 Feb 2013 16:18:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Feb 2013 16:18:04 +0000 (UTC) Cc: 13602@debbugs.gnu.org To: "'Dmitry Gutov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 04 17:18: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 1U2OkN-0006yx-E2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 17:18:19 +0100 Original-Received: from localhost ([::1]:46583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Ok4-0001t7-TL for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 11:18:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Ok2-0001sw-4z for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 11:17:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2Ok0-0006B9-EN for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 11:17:58 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Ok0-0006B4-Bb for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 11:17:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U2Ol3-0001HU-HG for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 11:19:01 -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:19: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.13599946964867 (code B ref 13602); Mon, 04 Feb 2013 16:19:01 +0000 Original-Received: (at 13602) by debbugs.gnu.org; 4 Feb 2013 16:18:16 +0000 Original-Received: from localhost ([127.0.0.1]:36183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2OkF-0001GL-5Z for submit@debbugs.gnu.org; Mon, 04 Feb 2013 11:18:15 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:25711) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2Ok8-0001G7-SS for 13602@debbugs.gnu.org; Mon, 04 Feb 2013 11:18:09 -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 r14GGv74015812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Feb 2013 16:16:58 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r14GGv4M016781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 16:16:57 GMT Original-Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r14GGurx011532; Mon, 4 Feb 2013 10:16:56 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Feb 2013 08:16:56 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87halsxr3q.fsf@yandex.ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4CybDokUVqKrDKSxGgEai+i1IM7QAJ3bSA 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:70681 Archived-At: > > Icomplete mode is general, for use with all minibuffers, > > whatever the kind of input being done (kind of completion > > or input without completion, etc.). > > No, it's not, it's only used in specific cases. > For example, icomplete is not used in minibuffer during > eval-expression. Nitpicking. Completion. That should have been understood from the context: "I _complete_" mode. Icompletion is about completion contexts. > > Let users bind them if they like. > > I'd like to comment on this as a ido-mode user. Great. But please recognize that not all Emacs users use Ido. And it is not even the default minibuffer behavior for Emacs. And it is not even described in the Emacs manual. IOW, your parochial point of view is of course welcome and relevant, but please don't mistake it for how users in general view using the minibuffer. > > In particular: C-s and C-r are used to search minibuffer > > text (e.g. move > > Instead of searching though the already entered text, ("Already entered" does not necessarily mean typed, BTW.) > this behavior allows you to "search" through the candidates. Yes, I know. So what? The point is that this substitutes the original, normal, usual behavior of those keys with another behavior. A given user can prefer either behavior: normal or new. Let users choose easily. That's the point. There are lots of Emacs users who have been using Icomplete for years (yes, even before Ido existed), and appreciate its informative help. You should not just assume, because you are an Ido enthusiast, that all users now want to switch to an Ido-like behavior for keys they have been able to use otherwise. > this strikes me as more appropriate. So in your case you would opt in to use the keys. What's the problem? (Though as an Ido user you really do not need Icomplete at all, do you?) You should get your way, for your own use. Another user should be able to get the longstanding Icomplete behavior, for her own use. It should be easy for each to get the behavior preferred, and even to switch to the other behavior. This is trivial to implement. What so much resistance to giving users the choice? Why so much insistence on bending Icomplete to be Ido-like for all? Users are free to use Ido if they like. Where's the beef?