|
From: | Le Wang |
Subject: | Re: Emacs needs truely useful flex matching |
Date: | Mon, 15 Apr 2013 08:14:44 +0800 |
>> "\\(\\<\\)?a\\([^b]*\\)\\(\\<\\)?b\\([^c]*\\)\\(\\<\\)?c\\([^d]*\\)\\(\\<\\)?d"I don't understand. The example I gave already has all the "\\<" we
>> > 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.
need, doesn't it?
> The algorithm works fast. I believe it has feature parity with SublimeSounds great. It does seem to require a fair bit of pre-processing, tho.
> 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.
When you say it's fast, does that include the time it takes to build the
hash tables from the list of potential candidates?
[Prev in Thread] | Current Thread | [Next in Thread] |