From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: icomplete-mode vs. iswitchb Date: Thu, 12 Dec 2013 14:26:58 +0200 Message-ID: <871u1iuuel.fsf@yandex.ru> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1386851242 16741 80.91.229.3 (12 Dec 2013 12:27:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Dec 2013 12:27:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Eglen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 12 13:27:26 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 1Vr5MU-0007rd-80 for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2013 13:27:26 +0100 Original-Received: from localhost ([::1]:35596 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr5MT-0002v2-Pp for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2013 07:27:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr5MM-0002ti-9y for emacs-devel@gnu.org; Thu, 12 Dec 2013 07:27:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vr5MG-0000fJ-Nh for emacs-devel@gnu.org; Thu, 12 Dec 2013 07:27:18 -0500 Original-Received: from mail-ee0-x22c.google.com ([2a00:1450:4013:c00::22c]:53514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr5MG-0000fC-GA for emacs-devel@gnu.org; Thu, 12 Dec 2013 07:27:12 -0500 Original-Received: by mail-ee0-f44.google.com with SMTP id b57so196970eek.3 for ; Thu, 12 Dec 2013 04:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=aK4ALcWSdnhlhf7h9RSXKdimHIBCjH0OJj4efq5ogTQ=; b=oZrH7/vNiuWes1n6WB+fm/GEoVJLdQbEbOrTJ5Sj5BujhXCxwwBu1Cuerd1N7eHEwp WsvQXN2Nb3HNvwBy4OxtyIYyuBTWKuWV1xpncwZ9sChG/UEY6u7rYdOZz94Rgi6ATEAG EaEje8dnhwuOthSPcspPixSl1MhS9PI7Kpn7yinGj/H2AyZhSk5AcLYEtzIzhQ5M1J6Z 8v33pnBvdVWC7vOU4BcTfDVITdz5yCbiSPEiFJ2IxjT6V79LRxlK4YMcWYmI3r4K8/AH 30qx4NakSDeUgMEN03pudFb25241F3kwKg93lENAEkgj33k6Uuf8dH5a5h/ROIuHPCyI L9YQ== X-Received: by 10.15.82.8 with SMTP id z8mr7720010eey.25.1386851231706; Thu, 12 Dec 2013 04:27:11 -0800 (PST) Original-Received: from axl (213-241-09.netrun.cytanet.com.cy. [213.7.241.9]) by mx.google.com with ESMTPSA id z42sm65412430eeo.17.2013.12.12.04.27.09 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 12 Dec 2013 04:27:10 -0800 (PST) In-Reply-To: (Stephen Eglen's message of "Thu, 12 Dec 2013 12:07:53 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22c 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:166329 Archived-At: Stephen Eglen writes: > Well, I don't recall many complaints about ido vs iswitchb -- most > people were happy to use one or the other. Probably more people use > ido, as it offers more features. But I have just tested this: > > (setq ido-mode 'buffer) > (ido-mode 1) Setting aside the fact that it doesn't do what you intended (ido-mode ends up set to `both', see this variable's docstring for details), if it did, the users would end up with less functionality than if they use icomplete-mode, which provides completion suggestions in all cases where Emacs knows how to complete - not only buffers, but files, functions, variables, etc. If we enable ido-mode for both buffers and files, we: - Still don't get completions in other cases (though there's a third-party package for that, called ido-ubiquitous). - Present users with a somewhat complicated behavior in `find-file' case. Off the top of my head, opening a non-existent file with name similar to one existing file is non-intuitive: I don't think we want to force users to look through documentation for that `C-j' binding.