fuzzy-matching in quickopen...

[Waqar Ahmed]

For the second screenshot, results are great for the query.
"search.ui" is a near perfect match. Instead if you had typed "sc",
which is much shorter, it would be most likely the first result. **For
the Nth time, You need to leverage the fuzzy stuff**.

"Prefer Open Files" and then giving a score of 1000 is just completely
wrong. Sorry. It is not "preferring" anymore, it is brutally bringing
up an open file even though it might be the worst possible match.
Thats not how it is supposed to work.

Btw, did you even try the MR where I tagged you?

I think what you want is a quickopen for openfiles only. That can be
added as a config, we can then ignore project files and just filter on
whatever is open. We can even allow an easier way to switch between
the two for e.g., when you type a particular symbol in the quickopen,
it switches to openfiles or reverse.



On Tue, Sep 27, 2022 at 1:55 AM Alexander Neundorf <neundorf at kde.org> wrote:
>
> 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