Stefan Monnier <address@hidden> writes:
>> But you didn't answer my question: what specific features of flx
>> are you looking for?
> - It's supposed to be particularly fast.
Not quite. The initial implementation was terribly slow. Then it became
usable at the expense of memory usage (caching), which is way higher
than it should be for a feature like this.
It is in my to-do list to implement the algorithm in C, either into
Emacs core or as an extension, and see if the speed improvement is good
enough to dispense with all the caching.
FWIW, I have a general intention with no concrete action as yet to work out how easiest to wire up fzf for matching, since it is extremely fast, reasonably memory efficient, and at least for me does a good heuristic job of matching things the way I expect them to match. The MIT license makes it possible to use as a module, though I also considered if a "pipe" mode akin to {i,a,hun}spell might be a smarter strategy.
This was motivated by my experience with flx, which was ... not positive, in terms of matching in the way I expected. It was better than the ".* between every letter" model that it replaced, however.