<div dir="auto">Rethinking some of the approaches, I think we can still improve in some ways.<div dir="auto"><br></div><div dir="auto">For example, matches which are not at start but still occur at a separation/camel Hump can be scored better. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div dir="auto">More boundaries can be considered, for example a `-` or `/`</div><div dir="auto"><br></div><div dir="auto">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. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 26, 2022, 2:13 AM Waqar Ahmed <<a href="mailto:waqar.17a@gmail.com">waqar.17a@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>You seem to think that an in sequence match should always be preferred. That's not how it works _by design_. And the examples you gave are not very good examples at all. If you are doing ese like searches for the given filenames, then don't expect good results, rather improve your searches instead so that the tool is able to help you better. </div><div dir="auto"><br></div><div dir="auto">- matches at the beginning are preferred because usually people tend to search stuff like that and because all other fuzzy filter implementations that I came across did the same thing. This is not changing, sorry. </div><div dir="auto">- in sequence matches are preferred once the pattern is >= 4. </div><div dir="auto"><br></div><div dir="auto">This is called fuzzy filter for a reason. It's not exact matching as you want it to be. </div><div dir="auto"><br></div><div dir="auto">I have created an MR which should prefer open files over non-open ones. If you can try that, it would be great. </div><div dir="auto"><br></div><div dir="auto">Thanks. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Sep 26, 2022, 1:49 AM Alexander Neundorf <<a href="mailto:neundorf@kde.org" target="_blank" rel="noreferrer">neundorf@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Samstag, 24. September 2022 00:06:34 CEST Waqar Ahmed wrote:<br>
> I am against adding the old way, but if it's optional, ok sure as long as<br>
> it is disabled by default.<br>
> <br>
> Your approach is completely incorrect though and the only reason I will say<br>
> ok to the patch is because Christoph already said ok. We can and should<br>
> improve the algorithm instead rather than just bringing back the old way on<br>
> the first complaint.<br>
<br>
Here are 3 examples (in the kate source tree) where the calculated score is <br>
IMO not good:<br>
<br>
I want to switch to "KateSearchCommand.cpp", which is already open.<br>
filter "ese":<br>
KateSearchCommand.cpp gets a score of 113<br>
MultilineStartEndOfLineMatch.txt gets a higher score of 116, even though it <br>
does not contain the string "ese", but only the "eS" and "E" with 4 characters <br>
inbetween<br>
I think a string which contains the filter exactly should get a higher score <br>
than a string which "just" contains the characters.<br>
<br>
<br>
filter "tes":<br>
KateSearchCommand.cpp score gets a score of 118 and comes in place 23, i.e. <br>
not visible without scrolling.<br>
tests.qrc score gets a higher score of 159, probably because it starts with <br>
"tes", but it is not open yet. There are about 20 files which start with <br>
"test", they are all not open.<br>
I often leave out the start of the filename, because often this is the same for <br>
many files in a project (e.g. "kate" in kate, or "q" in Qt, or "algo" in some <br>
other project), so I start typing with something in the middle of the filename.<br>
So I'd suggest that the "is open" bonus should be bigger than the "starts <br>
with" bonus.<br>
<br>
Different example: I want to switch to "kfts_fuzzy_match.h"<br>
filter "fts":<br>
kfts_fuzzy_match.h gets a score of 100<br>
filetree_model_test.cpp gets a higher score of 120. Again, I'd suggest that a <br>
string which contains the filter string exactly should get a higher score than <br>
a string which "just" contains the characters.<br>
<br>
The following gives IMO better results:<br>
<br>
bonus for "already open" = 15<br>
<br>
if (matched) {<br>
int sequentialBonus = 25;<br>
int separatorBonus = 10; // bonus if match occurs after a separator<br>
int camelBonus = 10; // bonus if match is uppercase and prev is lower<br>
int firstLetterBonus = 10; // bonus if the first letter is matched<br>
int leadingLetterPenalty = 0; // penalty applied for every letter in str <br>
before the first match<br>
int maxLeadingLetterPenalty = 0; // maximum penalty for leading letters<br>
int unmatchedLetterPenalty = -1; // penalty for every letter that doesn't <br>
matter<br>
int nonBeginSequenceBonus = 20;<br>
<br>
<br>
I'm not sure I understand this. Doesn't this mean that a long filename gets a <br>
big bonus ? <br>
// extra points if file exists in project root<br>
// This gives priority to the files at the root<br>
// of the project over others. This is important<br>
// because otherwise getting to root files may<br>
// not be that easy<br>
if (!matchPath) {<br>
score += (sm->idxToFilePath(sourceRow) == name) * name.size();<br>
<br>
<br>
Alex<br>
<br>
<br>
<br>
</blockquote></div></div></div>
</blockquote></div>