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 15:33:16 -0800 Message-ID: <1B35F54DD6314786947753464270A4A2@us.oracle.com> References: <65EEA895D8A0443A859A780AB233146E@us.oracle.com> <87halsxr3q.fsf@yandex.ru> <7C3C252294774DB79419E50757D7D7EB@us.oracle.com> <5110307D.3070908@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 1360020839 24502 80.91.229.3 (4 Feb 2013 23:33:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Feb 2013 23:33:59 +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 Tue Feb 05 00:34:19 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 1U2VYJ-0000F5-4P for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Feb 2013 00:34:19 +0100 Original-Received: from localhost ([::1]:48342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2VY0-0001ba-EL for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Feb 2013 18:34:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:37121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2VXx-0001az-02 for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 18:33:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2VXv-000753-3g for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 18:33:56 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2VXu-00074z-Vh for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 18:33:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U2VYz-0004kd-JV for bug-gnu-emacs@gnu.org; Mon, 04 Feb 2013 18:35: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 23:35: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.136002087118226 (code B ref 13602); Mon, 04 Feb 2013 23:35:01 +0000 Original-Received: (at 13602) by debbugs.gnu.org; 4 Feb 2013 23:34:31 +0000 Original-Received: from localhost ([127.0.0.1]:36536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2VYU-0004jt-IX for submit@debbugs.gnu.org; Mon, 04 Feb 2013 18:34:31 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:42837) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2VYR-0004jl-W6 for 13602@debbugs.gnu.org; Mon, 04 Feb 2013 18:34:29 -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 r14NXJX3012253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Feb 2013 23:33:19 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r14NXIoV026096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 23:33:19 GMT Original-Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r14NXIUb006424; Mon, 4 Feb 2013 17:33:18 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Feb 2013 15:33:18 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5110307D.3070908@yandex.ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4DI6XB5hk55GVeSweercbhQ+WniwAAMueg 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:70705 Archived-At: > My point is, as long as ido and icomplete are used in completion > situations, If you assume that Ido is used, then why use Icomplete too? > and they're used to complete relatively short things, Unwarranted assumption. (Of course, it depends on your "relatively".) And even when minibuffer content is relatively short, Isearch can be a quick way to move around: think cursor movement, not search. If you use Ido then you are perhaps not so used to editing and moving around the minibuffer text. But for those not using Ido, editing and moving around, including with isearch, are not uncommon. > they obviate the need for all three commands you're complaining about. No, they don't. And my complaint is not only about any particular three keys you might choose to co-opt by default. My beef is with co-opting any keys by default. Icomplete has a long, distinguished career helping Emacs users by passively showing the available completions and not interfering with any minibuffer key bindings (N.B. _any_). It should continue to offer that service that it does so well. If you want to add an optional mode that offers other, Ido-like things, fine. Just make it optional, please. > Searching back and forward though a short input string is > quite useless, See above. Searching to move around the minibuffer might be useless in Ido. But not everyone prefers to use Ido. But again, it's not about the particular keys. It's about stealing keys from their usual use in the Emacs minibuffer. Not the Ido minibuffer, which is quite special and atypical, but the Emacs minibuffer, in general. > >> 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. > > Is icomplete described in the Emacs manual? You're missing the point. _Emacs_ is described in the Emacs manual. This is about the Emacs minibuffer. Including the behavior you get from `emacs -Q'. That minibuffer behavior is described in the manual, yes. Icomplete has until now not interfered with that behavior, in particular with whatever keys are available in the minibuffer, in whatever mode, from whatever library, AFAIK. Icomplete has always played well with whatever minibuffer bindings you might use or prefer. It has only provided passive help: info about available completions. > I'm well-aware how Emacs looks and works by default, thank you very > much. It also has a rich ecosystems with packages modifying > its behavior every which way, according to user needs and whims. Good. And until now, Icomplete has played well with all of those users and their individual whims. It has not imposed key bindings. It should remain so well behaved and continue to be useful whatever bindings might be in effect, from emacs -Q or from other libraries. It gets along with so many modes in large part because it is keyless: it just provides info. Nearly every mode can take advantage of it, regardless of how that mode might define minibuffer behavior. It is indeed about the many Emacs users and their whims, and not just the whims of a developer or two. Let users easily get your preferred behavior, sure, but let them just as easily toggle that off and return to the bindings provided by emacs -Q or other packages they might choose. Why do you need to go all the way and impose your preferred behavior by default, and leave fiddling with keymaps as the only way to restore the bindings that would otherwise have remained current? > >> 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. > > icomplete is off by default, so no user is forced to use the > non-default behavior. The discussion is about Icomplete behavior. The default behavior of Icomplete. You are veering off the road. > > 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. > > Do I come across as a five-year-old or something? I'll have to let that one pass. > >> 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?) > > I don't. But you can make most of the same arguments in the > context of ido-mode, can't you? If you do not need Icomplete then why do you need it to interact like Ido? I do use Icomplete. And I want it to play well, for me and others, with emacs -Q and with other libraries that bind minibuffer keys. And no, I certainly would not make ANY of the same arguments wrt Ido that I've made about Icomplete. Icomplete is a long established mode that provides completion information. That simple help function serves a useful purpose. Until now Icomplete has not done anything else. Ido has from the beginning involved exceptional user interaction to choose candidates. It has never been something that you could use with the normal (e.g. emacs -Q) minibuffer interaction or with other-library minibuffer interactions. Ido radically alters minibuffer interaction - it plays by its own rules. It has provided its own, alternative minibuffer UI from the beginning. That is its raison d'etre. Nothing wrong with that; it is what Ido is intended to do. Totally different from Icomplete. You have not heard me make any suggestion about changing Ido behavior. > > You should get your way, for your own use. Another user > > should be able to get the longstanding Icomplete behavior, > > for her own use. > > ...maybe except this one. How long ago has this > "longstanding" behavior changed? Cannot parse that. Are you asking how old Icomplete is? Or when the last significant change in behavior was made to Icomplete? If so, I don't know the answer, but my guess would be that Icomplete is still essentially the same as it was designed to be, and it is quite old (decades). If you are really interested, you can do the archaeology to find the answers to what you are asking, whatever it is. > > 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? > > I believe most of the resistance is against your suggestion that the > minor mode with modified keybindings should be off by default. That's truly good to hear. So if we are agreed that users be able to easily toggle the behavior on/off, instead of telling them to go roll their own if they don't like the change, then let's move on to the question of the default: on or off. > If you hide nice things from users, some portion of users with never > find them. So, it hurts discoverability. Wonderful features have a way of being discovered, and I am sure this will have no problem in that regard. Discoverability seems a big deal when someone wants to announce their wonderful new feature - you want to make sure people don't miss the new 2014 car model, so you advertise it. Not needed here. Emacs advertises using NEWS, the manual, and menus. More important here should be leaving Icomplete to do its great job of passively showing help. I am in favor of keeping the traditional behavior by default. A non-Lisper who uses packages P and Q, which might bind some minibuffer keys, should not need to get out the Elisp manual to try to find a way to restore the bindings that P or Q provide, whenever Icomplete mode is turned on together with P or Q. By default, Icomplete should not change any minibuffer bindings. But whichever behavior is the default is far and away secondary to the matter of providing a quick toggle between the two behaviors. That is my primary concern. Even if we misguidedly let Icomplete impose bindings by default, a user should see in the Icomplete doc string that she can just toggle on or off a secondary mode that removes those bindings and restores whatever would be there otherwise. S?he should not be looking up the Lisp code of P, and digging into the Elisp manual, to find which keys to rebind and how, in order to get P's bindings each time.