From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Why fido, icycles, ido, icomplete Date: Thu, 07 Nov 2019 21:35:31 +0100 Message-ID: <87k18bctm4.fsf@telefonica.net> References: <20191106212018.cnddqzlo5rpdhi6s.ref@Ergus> <20191106212018.cnddqzlo5rpdhi6s@Ergus> <877e4c1x3r.fsf@gmail.com> <20191106232153.bb756hrf4ctwegkp@Ergus> <87ftj0eeum.fsf@telefonica.net> <20191107004718.pxb3m7hzecbxz7uu@Ergus> <8736f0e8an.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="223916"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 07 21:36:04 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iSoVf-000w8J-CY for ged-emacs-devel@m.gmane.org; Thu, 07 Nov 2019 21:36:03 +0100 Original-Received: from localhost ([::1]:47968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSoVc-0003Di-MD for ged-emacs-devel@m.gmane.org; Thu, 07 Nov 2019 15:36:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41971) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSoVM-0003Ch-0T for emacs-devel@gnu.org; Thu, 07 Nov 2019 15:35:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSoVK-0002ip-5o for emacs-devel@gnu.org; Thu, 07 Nov 2019 15:35:43 -0500 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:51944 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iSoVJ-0002gb-Tm for emacs-devel@gnu.org; Thu, 07 Nov 2019 15:35:42 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1iSoVH-000vj5-BE for emacs-devel@gnu.org; Thu, 07 Nov 2019 21:35:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:8Pyu9DZIJECXXpvK0xCdoXd5HFw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:241954 Archived-At: Stefan Monnier writes: [snip text which I fully agree with] > There are 2 ways to do that: > 1- improve ido.el > 2- write a replacement > > Both approaches are valid. Experience shows that approach number 2 has > been more popular. AFAIK only Ivy was created as a replacement for Ido+extensions. > Personally, I don't use IDO so I'm not particularly > interested in either approach's goal, but I do like some of IDO's > features, so I'm interested in solutions that result in a closer > integration of the "normal" completion code and IDO so I get to use > some the features I like without being forced to buy into the ones I > don't. > > That's why I wrote the `substring` completion style (which, together > with icomplete-mode (plus a few tweaks) made iswitchb obsolete, but more > importantly, it brought that feature to all users in the default config). > > IOW, I don't see fido-mode as "obsoleting ido-mode" but as "adding IDO > features to the standard completion system", IOW spreading IDO's > gospel further. I thought it was Ido who made iswitchb obsolete ;-) but I get your point about expanding the capabilities of the default method to cater the needs of more users. Just to clarify, it is great to see João working on this. As for the future of Ido, I'm not terribly afraid: supposing it is obsoleted and the replacement does not fit my needs, the solution is obvious and not all that painful. > Here as some examples of the corner cases supported by the standard > completion system and that IDO currently doesn't cover, AFAICT: > - C-x C-f by default can complete env vars, e.g. when you type C-x C-f $HOM TAB > - C-x C-f ${HOM TAB will not only complete the "E" but will also close > the "}", at least if there's no other env var starting with "HOME". > - IDO doesn't support some completion styles such as `partial-completion` > E.g. C-x C-f ~/e/s/r-e.c TAB to find the ~/emacs/src/regex-emacs.c file. > - By default IDO only covers minibuffer completion of files and buffers. > ido-completing-read makes it cover all minibuffer completions, but > there's still no support for in-buffer completion. > - the *Completions* buffer (and icomplete-mode's in-buffer list of > completions [tho I now notice that some of the highlighting is lost in > some cases, looks like a bug]) highlights the parts of the candidates > that matched the pattern, as well as the place that correspond to where > "point" is. Good, but keep in mind that different approaches to completion can make some of the above moot. Take the *Completions* buffer, for example. On my Ido config, there is visual feedback about the parts of the candidate strings that matches the query and they are shown on a multi-column format that is dense and readable at the same time, IMO. As I mentioned on a previous message, there is more than one way to skin a cat. Having a powerful and flexible (*) default completion method is great, but other approaches perhaps require things that does not fit with whatever framework you can provide. * There is a tendency on modern software towards dumbing-down things, for a good reason, but IMAO Emacs should not do down that path.