From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: icomplete-mode vs. iswitchb Date: Wed, 11 Dec 2013 22:33:11 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1386819215 10979 80.91.229.3 (12 Dec 2013 03:33:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Dec 2013 03:33:35 +0000 (UTC) Cc: Stephen Eglen , emacs-devel To: Josh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 12 04:33:39 2013 Return-path: Envelope-to: ged-emacs-devel@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 1Vqx1u-0001gA-E9 for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2013 04:33:38 +0100 Original-Received: from localhost ([::1]:33114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqx1t-00041C-FS for ged-emacs-devel@m.gmane.org; Wed, 11 Dec 2013 22:33:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqx1j-00040q-OY for emacs-devel@gnu.org; Wed, 11 Dec 2013 22:33:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vqx1c-00085N-Fb for emacs-devel@gnu.org; Wed, 11 Dec 2013 22:33:27 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqx1c-00085H-AP for emacs-devel@gnu.org; Wed, 11 Dec 2013 22:33:20 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id rBC3XCRh026704; Wed, 11 Dec 2013 22:33:13 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 182D5AE25E; Wed, 11 Dec 2013 22:33:11 -0500 (EST) In-Reply-To: (josh@foxtail.org's message of "Wed, 11 Dec 2013 10:09:08 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4789=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4789> : inlines <312> : streams <1089339> : uri <1621458> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:166318 Archived-At: >>> favor is Stefan's presumption that the package preferred by the >>> majority of users could not be configured to behave like the package >>> preferred by a far smaller minority. >> WTF are you talking about? IDO is just as available as ever. > Are you being deliberately obtuse or do you read as selectively as you > quote? You have said that icomplete is to replace iswitchb. Which has nothing to do with IDO. > I have argued that ido would be a more suitable replacement because > all of the available evidence strongly suggests that users prefer ido > over icomplete by a wide margin, not to mention the fact that > a substantial amount of library and user code is built on top of ido. That's fine, but the reason why we've had iswitchb until now is because apparently IDO was not a replacement, but rather another feature which took iswtchb's and then added a host of other things. And this situation hasn't changed, so no, AFAIK, ido is not a replacement for iswitchb. To put it some other way: where were you all in the last 10 years or so that we've had iswitchb and ido, without complaining that we should mark iswitchb as obsolete and replace it with ido? > There is an ongoing discussion about features that ought to be enabled > by default to improve the experience of new users and this discussion > has largely been based on features' current popularity, about which we > now have good insight thanks to the efforts of those who have > extracted that information from bug reports and who have organized and > participated in the wiki poll. In this context it seems obvious that > such a popular library as ido should be enabled by default, but > instead you have chosen the polar opposite for ido, to "slowly > obsolete" it for reasons unknown. Can you seriously not see how this > appears irrational? I already said that enabling IDO by default is not on the table not because IDO doesn't provide nice features but because: - it's not a superset of the current completion UI features (it doesn't understand all the new completion table features). - it is not fully "ui compatible", in that several keybindings clash in very significant ways with the current completion. I fully agree that we'd like to make some/many of the features offered by IDO available by default, but since enabling IDO is not an option, the second best is to slowly integrate the two, which is not a small undertaking. Stefan