[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs needs truely useful flex matching
From: |
Le Wang |
Subject: |
Re: Emacs needs truely useful flex matching |
Date: |
Fri, 22 Mar 2013 09:00:14 +0800 |
On Fri, Mar 22, 2013 at 7:58 AM, Stefan Monnier
<address@hidden> wrote:
>>> 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).
I hadn't thought of this, and I'll try it soon.
> Have you tried such an approach and it really was too slow?
> I'd welcome a new completion-style using the above flex matching.
You're right that in generally that my claim of "emacs-lisp would be
too slow" needs to be verified.
>> 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.
"git ls-files" is very fast on a solid state drive, and the list can
also be cached. But let's assume we already have the list of strings.
--
Le
Re: Emacs needs truely useful flex matching, Richard Stallman, 2013/03/21