[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why fido, icycles, ido, icomplete

From: Óscar Fuentes
Subject: Re: Why fido, icycles, ido, icomplete
Date: Thu, 07 Nov 2019 02:51:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Ergus <address@hidden> writes:

>>It takes a set of candidates and a string as inputs. The algorithm
>>associates a score to each candidate based on the string and outputs a
>>list of matching candidates sorted by the score.
> 1) Is this what amx (former smex) does?

I don't know amx/smex but AFAIK there is only one implementation of the
flx algorithm on the Emacs universe. Alos, smex predates flx.

> if 1) is it like: ivy???regex-fuzzy + amx?

No, IIRC regex-fuzzy turn abc into .*a.*b.*c but flx is much more
comples and the scoring algorithm is the key difference. flx scores
candidates depending on where each letter matches. For instance, if I

M-x sbke

the first candidate is save-buffers-kill-emacs, because it is the
candidate that gets the higher score by far.

Similarly, when I use my custom command for visiting a file on a git
repo that presents as initial candidates all the files obtained through
`git ls-files', typing "sxc" on the Emacs git checkout puts
source/xdisp.c as the second candidate (the first is
etc/xhtml-csismap.rnc) and if I type "lide" the fifth candidate is

This last example is penalized because the algorithm gives higher scores
to candidates with longer names, which is also the reason why
source/xdisp.c is not the first candidate on the previous example.

But once we understand the algorithm, we know that the "e" in "lide"
does not help because every file inside lisp/ has an ".el" suffix.
Simply typing "lid" lisp/ido.el is already the fifth candidate but
getting rid of the useless "e" and typing "lido" puts that file as the
first candidate.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]