fuzzy-matching in quickopen...

Alexander Neundorf neundorf at kde.org
Mon Sep 26 21:55:12 BST 2022


On Sonntag, 25. September 2022 23:57:32 CEST Waqar Ahmed wrote:
> Rethinking some of the approaches, I think we can still improve in some
> ways.
> 
> For example, matches which are not at start but still occur at a
> separation/camel Hump can be scored better.
> 
> Gap between two matched letters can be taken into account so that really
> bad matches are scored lower for example the image-match in your initial
> email. This would also improve results for in sequence matches vs matches
> that are at separation but the distance is too long. Need to think through
> this well though.
> 
> Camel/separation/acronym matches could be scored lower for example when a
> letter in between is just a normal match and not a separator match e.g:
> 
> FooBarTaz with pattern "fot". F and T both get full separator scores even
> though there is o in between which didn't get matched and thus its likely
> this isn't what the user wanted
> 
> More boundaries can be considered, for example a `-` or `/`

Sounds good :-)

> But all this needs a lot of testing. For you it may seem like, let's just
> adjust scores and be done, but understand that I have spent countless hours
> even days tuning the algorithm for various things.

Yes, I can imagine that.

Attached there are two screenshots which show why IMO the bonus for "starts at 
the beginning" should be small.

One shows the results when typing "kate". Many files in kate start with "kate". 
If I want to get a high score later on, I need to start with the beginning of 
the word, i.e. "kate", but the list of matching files is still very long with 
that. So I had to type 4 characters, not to filter out non-matching files, but 
to get a higher score for what I will type after.

The second screenshot shows the result of entering "search". 
KateSearchCommand.cpp, which is already open, ends up quite far down in the 
list (with a score of of 291), while the files starting with "search" get 
scores around 450. 

How about a config option "Prefer open files" which changes the bonus for open 
files from 1 to 1000 ?
Then the calculation of the score would still have the intended effect, but 
basically separately for files which are already open and files which are not 
open ?

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: quickopen-kate-prefix.png
Type: image/png
Size: 51366 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20220926/b5f4d69f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: quickopen-search.png
Type: image/png
Size: 66628 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20220926/b5f4d69f/attachment-0003.png>


More information about the KWrite-Devel mailing list