[Top][All Lists]

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

Re: Emacs needs truely useful flex matching

From: Stefan Monnier
Subject: Re: Emacs needs truely useful flex matching
Date: Sun, 14 Apr 2013 14:18:09 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>> "\\(\\<\\)?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).
>> I hadn't thought of this, and I'll try it soon.
> I gave this a good try.  :-)
> Since we are favouring beginning of word anchors (often but not always), I
> actually had to insert "\\<" in the various slots in front of characters.
> That is all permutations of 4x"\\<", then 3x, then 2x, then 1x, etc.

I don't understand.  The example I gave already has all the "\\<" we
need, doesn't it?

> The algorithm works fast.  I believe it has feature parity with Sublime
> Text's fuzzy search.
> However it uses a fair bit of memory,
> 1. it's allocating one hash table and one same-length vector for each string
> 2. it's allocating one cons cell for each character.

Sounds great.  It does seem to require a fair bit of pre-processing, tho.
When you say it's fast, does that include the time it takes to build the
hash tables from the list of potential candidates?


reply via email to

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