Re: Why fido, icycles, ido, icomplete

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Wed, Nov 6, 2019 at 10:39 PM Óscar Fuentes <ofv@wanadoo.es> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > Now, I wish I could just put 'flex' (and many other things) in
> > ido-mode.
>
> Ido has a `flex' completion style. Maybe it is a different one?
>

Yes it is. I created the flex completion style so it could be used
across the board, in every completion frontend, not just icomplete.


> Should it? This is like the recent discussion about implementing new
> commands on VC: insisting on a common interface hampers diversity and
> innovation. We must accept that different tools sometimes deserve
> specific user interfaces.
>

Sure, but we're not talking about user-facing interfaces here, rather about
interfaces between reusable components of Emacs.


> > This
> > means it doesn't work nicely for M-x, C-h f, and many many other
> > completion situations.
>
> Ido works nicely here for those cases with just a few lines on my .emacs
> and an extra package installed (ido-hacks).
>

But it won't work with, say SLY's capf-abiding completion table.
Or Eglot's (or lsp-mode's for that matter).

I think the name of the package you use to do that also
says something about the quality of the integration. :-)


> This indicates to me that ido is more hackable than your message
> implies. I'm not denying that it could be much better on that regard,
> though.
>

But those additions only bring it farther away from integrating
into Emacs's completion facilities, and reaping those benefits.

You'll have to write a package to make ido-mode use Helm's
super-special matching styles, but you won't for icomplete.

But I didn't mean to knock ido-mode.  When I'm in a tight spot
on someone else's contorted Emacs, it's still my goto M-x.

It sounds like you're an ido-mode fan, so please try out
fido-mode and tell me what you think is missing from it. I
know a lot is, and I want to improve it.

João

[-- Attachment #2: Type: text/html, Size: 3176 bytes --]