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: Thu, 7 Feb 2013 13:32:31 -0800 Message-ID: <34B98B513D9349CA9C8819AE35F22D7A@us.oracle.com> References: <65EEA895D8A0443A859A780AB233146E@us.oracle.com><625A327B282C4C279837A7542B76E5C8@us.oracle.com><87zjzk112u.fsf@gmail.com><20DF11E25EE542A1A334DA1FDB79F77B@us.oracle.com><87bobz7ajl.fsf@gmail.com><87bobys6yc.fsf@mail.jurta.org><87wquluiks.fsf@mail.jurta.org> <87txpon5mk.fsf@gmail.com><87a9rgo959.fsf@mail.jurta.org> 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 1360272797 14895 80.91.229.3 (7 Feb 2013 21:33:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Feb 2013 21:33:17 +0000 (UTC) Cc: 13602@debbugs.gnu.org, 'Jambunathan K' To: "'Stefan Monnier'" , "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 07 22:33:36 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 1U3Z65-0005is-Fg for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Feb 2013 22:33:33 +0100 Original-Received: from localhost ([::1]:56217 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3Z5j-00035M-B1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Feb 2013 16:33:11 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3Z5d-00033S-K7 for bug-gnu-emacs@gnu.org; Thu, 07 Feb 2013 16:33:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3Z5b-00074E-M4 for bug-gnu-emacs@gnu.org; Thu, 07 Feb 2013 16:33:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3Z5b-000747-IR for bug-gnu-emacs@gnu.org; Thu, 07 Feb 2013 16:33:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U3Z5a-0007nn-2r for bug-gnu-emacs@gnu.org; Thu, 07 Feb 2013 16:33: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: Thu, 07 Feb 2013 21:33: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.136027276129962 (code B ref 13602); Thu, 07 Feb 2013 21:33:02 +0000 Original-Received: (at 13602) by debbugs.gnu.org; 7 Feb 2013 21:32:41 +0000 Original-Received: from localhost ([127.0.0.1]:42513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U3Z5C-0007nB-Fp for submit@debbugs.gnu.org; Thu, 07 Feb 2013 16:32:40 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:30492) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U3Z59-0007n2-MB for 13602@debbugs.gnu.org; Thu, 07 Feb 2013 16:32:37 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r17LWYOp001110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Feb 2013 21:32:34 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r17LWXeB001893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2013 21:32:33 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r17LWWxY027534; Thu, 7 Feb 2013 15:32:32 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Feb 2013 13:32:32 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac4FPeyLYrgBymWiRJWLbuDpfHUrIQAEZTwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:70846 Archived-At: Ironic. The imposition of key bindings on Icomplete is being promoted by Ido enthusiasts who have no real need for it since they use Ido, which does the same thing. Who does use Icomplete, and who will thus receive this gift not needed by its donors? Users who _do_ edit minibuffer contents. Icomplete is really for non-Ido users. It is used in an ordinary, non-Ido minibuffer. Imposing Ido keys on it (as opposed to just offering them as an option), and thus taking away normal editing keys, is questionable, if not misquided. Why this is being promoted so forcefully by people who presumably will not use Icomplete is a wonder. It makes little difference which keys are chosen for these bindings. Whatever they are, they can conflict with keys used otherwise in the minibuffer, whether those keys come from bare emacs -Q or from some other code. I don't understand the refusal to let users choose easily whether they want Icomplete to bind keys. What's the problem with that? I've asked this several times and not once gotten an answer. Why the avoidance to confront the question head-on? Instead of presenting reasons why this choice should be refused (only silence there so far), there are attempts to divert the argument to how particular keys are used - essentially a red herring. When Juri mentions C-r and C-s, we get a lecture on how one can work around the problem, Ido-style. > One doesn't need to rely on traditional "C-r" exclusively to > accomplish the above work flow. Need? Rely? Exclusively? Shades of "Let them eat cake". Ultimately, we get some admission that maybe C-s and C-r are not the best choices after all... So the diversion turns to a search for other keys (C-S-s...). It does not matter here how Juri uses C-s or any other key - whether he really "needs" to or how frequently he does so. It does not matter whether Ido users have found some other nifty way to accomplish the same thing as this or that ordinary editing practice. Some users _do_ edit, search, copy, and otherwise do things to their minibuffer input. And there is _no reason_ to try to shoehorn all such practice into an Ido shoe. No reason to present workarounds demonstrating that you can really do whatever you want in spite of the imposition of Ido keys. No need for any of that - just make the bindings optional, please. Ido does not use the minibuffer in the usual way at all. Its keys and its behavior are special, unusual, atypical for Emacs. But more importantly, the problem is not this or that key. The problem is binding any keys at all and not giving users a simple way to do without such bindings. How about it? Why not give users an option, and a toggle command?