From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Josh Newsgroups: gmane.emacs.devel Subject: Re: icomplete-mode vs. iswitchb Date: Thu, 12 Dec 2013 09:15:21 -0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1386868560 3146 80.91.229.3 (12 Dec 2013 17:16:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Dec 2013 17:16:00 +0000 (UTC) Cc: Stephen Eglen , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 12 18:16:06 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 1Vr9rp-00080G-H1 for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2013 18:16:05 +0100 Original-Received: from localhost ([::1]:37823 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr9ro-0005b9-Tf for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2013 12:16:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr9rh-0005b0-V3 for emacs-devel@gnu.org; Thu, 12 Dec 2013 12:16:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vr9rd-0005Sg-9Y for emacs-devel@gnu.org; Thu, 12 Dec 2013 12:15:57 -0500 Original-Received: from mail-wg0-f43.google.com ([74.125.82.43]:65149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr9rc-0005Sa-WB for emacs-devel@gnu.org; Thu, 12 Dec 2013 12:15:53 -0500 Original-Received: by mail-wg0-f43.google.com with SMTP id k14so727962wgh.34 for ; Thu, 12 Dec 2013 09:15:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=wyJE43nWMB5QeWdRWPdjFpU2WG0j30fwArJ8y9+WvFE=; b=kafzDIUQUY5m4P2Vvo5dXhYQTLRgFllgHYBspdgEfzF9Kf7p74ElWPDcY+qM4IgYP2 SZdLOk4srwuGJXxHjBFtRBuoRGfEk2H4OiRVtyUFpuBe+7MB+Ij8/HcwgoTohfG4K/Uk 37oC/yA0bNNTAqgF8vzJtI7MJPDx/BiPXQg14tken8tm2RqyIKKwCPIjgrpcsXPht2C2 1pqI+mVHgHZKeG6/9P8MW3BW8s2rUHa8llnSSnNotjM0jt3OqD1hK5vuwtUzBifZjVSO qdJWf7u97YEcqHu5ZHOq9Ar67yG2JKDGWYu7/E2c5VPcxr90WGvhFHMKICqdKUBkD0vq dO9Q== X-Gm-Message-State: ALoCoQnHB/rtmXKDJfmPZ3pw/Jtdrx5ydcTmf6ueJQExKjDcSCEnkCcUR1kL6+sX4iOgYZJzVhpw X-Received: by 10.180.171.34 with SMTP id ar2mr23015863wic.25.1386868552084; Thu, 12 Dec 2013 09:15:52 -0800 (PST) Original-Received: by 10.194.24.7 with HTTP; Thu, 12 Dec 2013 09:15:21 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 8OgqKvK9GnS1BEzfRCbAm6E_Aqc X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.43 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:166340 Archived-At: On Wed, Dec 11, 2013 at 7:33 PM, Stefan Monnier wrote: > 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? I have been happily using ido. I already told you that I know others who have been happily using iswitchb. Why should I complain and agitate to get something that my friends like obsoleted? >> 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). Actually enumerating the ways in which it falls short would help interested people understand the scope of the problem and perhaps take on adding support for those features. > - it is not fully "ui compatible", in that several keybindings clash in > very significant ways with the current completion. I suppose you're talking about C-s and C-r here; are there others? In any case, such bindings could be trivially changed to adhere to the current completion key binding conventions and then exposing a simple disabled-by-default "classic ido key bindings" customization to retain the existing UI for those of us who prefer it. The most frequent complaint I hear about ido is the one Dmitry mentioned about C-j for finding new files; I agree that this behavior is non-intuitive and undesirable for new users, but it seems likely that we could work out a more intuitive default interface and make the current behavior opt-in for experienced ido users. > I fully agree that we'd like to make some/many of the features offered > by IDO available by default, As I have pointed out, there is quite a bit of library and user code built on top of ido, i.e. depending on its current interfaces and behavior, so "offering the features" is not sufficient to avoid breaking that code. > but since enabling IDO is not an option, > the second best is to slowly integrate the two, which is not > a small undertaking. Would it be an option if support were added for the current completion UI features you mentioned and the key bindings were harmonized with current completion key binding conventions? If so, will you please enumerate the missing features? If not, what else stands in the way?