From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Le Wang Newsgroups: gmane.emacs.devel Subject: Re: flx -- flex with better sorting Date: Thu, 2 May 2013 00:26:47 +0800 Message-ID: References: <87ip32ofdn.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b5d8cff97611c04dbaa95ff X-Trace: ger.gmane.org 1367425618 25719 80.91.229.3 (1 May 2013 16:26:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 May 2013 16:26:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?ISO-8859-1?Q?=D3scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 01 18:26:55 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UXZrp-0003z1-Fn for ged-emacs-devel@m.gmane.org; Wed, 01 May 2013 18:26:53 +0200 Original-Received: from localhost ([::1]:42085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZrp-0003XM-3X for ged-emacs-devel@m.gmane.org; Wed, 01 May 2013 12:26:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZrm-0003WC-6d for emacs-devel@gnu.org; Wed, 01 May 2013 12:26:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXZrk-0005km-HB for emacs-devel@gnu.org; Wed, 01 May 2013 12:26:50 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:59474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXZrk-0005ka-6u for emacs-devel@gnu.org; Wed, 01 May 2013 12:26:48 -0400 Original-Received: by mail-wi0-f173.google.com with SMTP id c10so5062261wiw.6 for ; Wed, 01 May 2013 09:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ABIop0i2m58ip1RmOgkZIUWIWHzYGwHkipnH4CF5zAQ=; b=cfxfaJWfsdC+Wvn13rsm+IDT3fZNuzxlCFQbQObEjiAmCG9hh5Kj53gVV/JAYENrHY NAPQvotx09J29fiS0O4zhbVn9ZdZ8uLYhwXZ96MNIFvHJ4dtW+Yae9ChFUzubX1AWmBO 4I/IV3H1BhuRB8G9PHF4nhNdgYB+i9ESdmg+xc38UIVndetSMgoo+eZjDiiKGmTVlgS9 6+brVyCz/XquJ4ItECavI6fXCLgWjDVl7NIl5GUjsafZ4arKvFpJcS/wj5FyjmBDL6cf 1kSBuz4jmmdTqMrnTdluJB3x4OQQnhDvUAyQ94MXwd6wWCz0+JvRcSQ44SPBSs3N7BYo SuZg== X-Received: by 10.194.93.68 with SMTP id cs4mr3630646wjb.17.1367425607489; Wed, 01 May 2013 09:26:47 -0700 (PDT) Original-Received: by 10.217.116.8 with HTTP; Wed, 1 May 2013 09:26:47 -0700 (PDT) In-Reply-To: <87ip32ofdn.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159245 Archived-At: --047d7b5d8cff97611c04dbaa95ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, May 2, 2013 at 12:04 AM, =D3scar Fuentes wrote: > From trying it for a few minutes with ido: > > 1. I like it. Looks much better that ido's flex matching. > Thanks. 2. Working with 10500 candidate files, there is a noticeable pause the > first time ido-complete is invoked. I'm using a reasonably fast > machine and the pause is not annoying, but that perception may change > when using less capable machines. > Yep, it's adding these candidates to the cached hash. > 3. With the same set of candidates, RES memory jumps from 35 MB to 70 MB > on first use (on a 64 bit GNU/Linux machine). This is a more serious > concern. > Yep. I mentioned this in my first thread that the algorithm trades memory usage for speed. I'm not sure how to optimize this part. > 4. Sometimes it fails to work as advertised. For instance, if I type > `ltx' this file is shown first on the list of matches: > > lib/Target/NVPTX/NVPTXLowerAggrCopies.h > > but I would expect > > lib/Target/X86/* (* meaning any file under that subdirectory). > 1. The algorithm favors basepaths heavily. 2. I ended up considering all capitals to be beginning of word. This means ltx is matching as expected. As you supply more letters, better results should float to the top. I made a helm demo that shows scoring of each match. If you're curious, just replace the hardcoded list of files with your own list and run it through helm. (btw, helm integration still doesn't work) Furthermore, when inputting `ltx8', matching letters on candidates are > highlighted like this: > > lib/Target/X86/X86TargetTransformInfo.cpp > ^ ^ ^^ > > It ignores the first occurrence of `X8'. > The letters that made the best score is highlighted. See: favoring basename. > 5. Another quirk is that it rejects capital letters. For instance, if I > type `lT' it shows no matches, but in fact there are lots of files > like this: > > lib/Target/... > > Actually, typing just `T' fails to find any candidate, but there are > lots files with a capital T on its name. > I hadn't considered people might do this. :-) Will fix soon. --=20 Le --047d7b5d8cff97611c04dbaa95ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 2, 2013 at 12:04 AM, =D3scar Fuentes <ofv@wanado= o.es> wrote:
From trying it for a few minu= tes with ido:

1. I like it. Looks much better that ido's flex matching.

Thanks.=A0

2. Working with 10500 candidate files, there is a noticeable pause the
=A0 =A0first time ido-complete is invoked. I'm using a reasonably fast<= br> =A0 =A0machine and the pause is not annoying, but that perception may chang= e
=A0 =A0when using less capable machines.

Yep, it's adding these candidates to the cached hash.
=A0
3. With the same set of candidates, RES memory jumps from 35 MB to 70 MB =A0 =A0on first use (on a 64 bit GNU/Linux machine). This is a more serious=
=A0 =A0concern.

Yep. =A0I mentioned thi= s in my first thread that the algorithm trades memory usage for speed. =A0I= 'm not sure how to optimize this part.
=A0
4. Sometimes it fails to work as advertised. For instance, if I type
=A0 =A0`ltx' this file is shown first on the list of matches:

lib/Target/NVPTX/NVPTXLowerAggrCopies.h

but I would expect

lib/Target/X86/* (* meaning any file under that subdirectory).

1. The algorithm favors basepaths heavily.
2. I ended up considering all capitals to be beginning of wor= d.

This means ltx is matching as expected. =A0= As you supply more letters, better results should float to the top.
=A0
I made a helm demo that shows scoring of each match.= =A0If you're curious, just replace the hardcoded list of files with yo= ur own list and run it through helm. =A0(btw, helm integration still doesn&= #39;t work)

Furthermore, when inputting `ltx8', matching letters on candidates are<= br> highlighted like this:

lib/Target/X86/X86TargetTransformInfo.cpp
^ =A0 ^ =A0 =A0 =A0 =A0 =A0^^

It ignores the first occurrence of `X8'.

The letters that made the best score is highlighted. =A0See: fa= voring basename.
=A0
5. Another quirk is that it rejects capital letters. For instance, if I
=A0 =A0type `lT' it shows no matches, but in fact there are lots of fil= es
=A0 =A0like this:

lib/Target/...

Actually, typing just `T' fails to find any candidate, but there are lots files with a capital T on its name.

I hadn't consid= ered people might do this. =A0:-) =A0Will fix soon.


--
Le
--047d7b5d8cff97611c04dbaa95ff--