Re: Emacs needs truely useful flex matching

[Stefan Monnier]

>> The sorting algorithm is roughly this for a query: "abcd"
>> 
>> 1. Get all matches for "a.*b.*c.*c"
>> 2. Calculate score of each match
>> - contiguous matched chars gets a boost
>> - matches at word and camelCase boundaries (abbreviation) get a boost
>> - matches with smallest starting index gets a boost
>> 2. Sort list according to score.

I think that if you turn "abcd" into a regexp of the form
"\\(\\<\\)?a\\([^b]*\\)\\(\\<\\)?b\\([^c]*\\)\\(\\<\\)?c\\([^d]*\\)\\(\\<\\)?d"
the regexp matching should be fairly efficient and you should be able to
compute the score efficiently as well (at least if
you ignore the camelCase boundaries).

>> This navigation could be implemented with Helm if Emacs had a builtin
>> fast smart flex sorting engine.

Have you tried such an approach and it really was too slow?
I'd welcome a new completion-style using the above flex matching.

> IIUC the vim plugin you mention depends on a pre-built list of files.

Indeed when searching for a file in a file hierarchy, you'd need
a pre-built list of files, otherwise the time taken to find the files
would dwarf the flex-matching time in any case.


        Stefan