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 23:18:39 +0100 Message-ID: <87bltncou8.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> <87k18bctm4.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="129063"; 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 23:20:11 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 1iSq8R-000XQT-2g for ged-emacs-devel@m.gmane.org; Thu, 07 Nov 2019 23:20:11 +0100 Original-Received: from localhost ([::1]:48526 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSq8P-00071D-OG for ged-emacs-devel@m.gmane.org; Thu, 07 Nov 2019 17:20:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51311) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSq7C-00070z-Mw for emacs-devel@gnu.org; Thu, 07 Nov 2019 17:18:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSq7B-0006J2-Du for emacs-devel@gnu.org; Thu, 07 Nov 2019 17:18:54 -0500 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:56604 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iSq7B-0006Go-5w for emacs-devel@gnu.org; Thu, 07 Nov 2019 17:18:53 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1iSq74-000VZL-16 for emacs-devel@gnu.org; Thu, 07 Nov 2019 23:18:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:U7MhHOBJPxUCFn+MiDTOtHAs2A4= 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:241958 Archived-At: Stefan Monnier writes: >> 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. > > Great, I wasn't aware that it had been implemented for IDO. As an extension, yes. Below is my Ido-related config. It extends Ido completion to almost all Emacs, activates flx and changes the way candidates are displayed. Those customizations replace Ido's candidate-handling algorithm and dramatically alters its UI. So much for an unintelligible package :-) (setq ido-save-directory-list-file nil) (put 'tmm-menubar 'ido 'ignore) (require 'ido-hacks) (ido-hacks-mode) (ido-mode 1) (ido-everywhere) (setq ido-enable-tramp-completion nil) (setq ido-auto-merge-work-directories-length -1) (setq ido-enable-flex-matching t) (require 'flx-ido) (flx-ido-mode 1) ;; disable ido faces to see flx highlights. (setq ido-use-faces nil) (setq flx-ido-threshold 20000) (require 'ido-grid-mode) (ido-grid-mode 1) (setq ido-grid-mode-prefix-scrolls t) >> 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. > > Definitely. Emacs makes it particularly easy to experiment this way and > develop solutions tuned for very specific situations. IDO is a great > such example. The number of "completion frameworks" out there for Emacs > is another example. > > I see the task of Emacs maintainers as trying to consolidate those > "branches" of functionality so that their features can be used in > more circumstances. Usually that only applies to some parts of the > functionality they offer, and very often it requires a complete rewrite > of those features. > > The hardest part is often how to retrofit the "generic implementation" > of a feature into the package which originally first provided this > feature in an "ad-hoc" way, since as a general rule the generic > implementation isn't a perfect match. What you say is very reasonable but sometimes this task is not worth the trouble (I'm not claiming that it's the case for fido-mode). There is always a tension among specifics and generalities. Sometimes it is irreconcilable. I don't see VC ever providing a better Magit than Magit itself and Magit would never come to existence if Marius insisted on implemeting it inside VC, simply because Magit has the goal of being the best UI for git and VC has the goal of being the best generic VCS UI. Does it make sense to expand Emacs' functions towards unifying those packages? Not at all, because they are only related on a superficial way.