Re: Why fido, icycles, ido, icomplete

[Óscar Fuentes]

Stefan Monnier <address@hidden> 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.