fuzzy-matching in quickopen...

[Waqar Ahmed]

1. After filtering, why should open files always end up at top? This
is not an "already open files quickopen". If the filter matches
something else better that will end up at top. There might be cases
where an openfile is a better match, perhaps there is a way to improve
that without biasing 100% in favour of open files.

2. Match in sequence will take precedence once you have typed 4 or
more letters. With 3 or less letters, we can't be sure if that is a
sequence or an abbreviation. e.g., ftv will prefer "FilesTreeView"
over "abcftv.js"

3. That is correct and working as expected.

Quickopen is not meant to filter already open files. For that, you
have other plugins that can do the job.

If you have a concrete case where X is a better match, discussing that
would be better.

On Fri, Sep 16, 2022 at 3:11 AM Alexander Neundorf <neundorf at kde.org> wrote:
>
> Hi,
>
> I updated my kate (since quite some time) again, and the new fuzzy matching
> makes the quickopen in some cases close to unusable for me.
>
> 1) files which match and which are already open do not always end up at the top
> after filtering.
> So if I type some letters, now, many files match, including files which I have
> not opened yet, and the one I want (where I was maybe 3 files ago) does not
> even end up on the first page of results, but somewhere deep down. If I have to
> scroll and search with my eyes for the correct file, it is not a "quick" open
> anymore...
>
> 2) it matches just too much, or at least the scores are not good. Let's say I
> want to open a file named "creategdt.cpp", so I type "gdt". This will match all
> files which contain a "g", a "d" and a "t" somewhere in their name, like let's
> say "globaldestructor.cpp". The files which actually have "gdt" in their name,
> do not necessarily end up at the top of the list, but I have to search and
> scroll.
> As another example, when typing "cmake", it now among others suggest "color-
> themes-gui-breeze-dark-default-text-styles.png." I think this is so far off
> that it is not useful.
>
> 3) it seems to be somewhat case sensitive. If I enter "c", it does not show
> "CMakeLists.txt". If I enter more than 1 letter, it seems to become case
> insensitive.
>
> I would actually prefer to revert back to the old matching. 1) IMO needs to be
> restored, files which are open should always be above files which are not open.
> Maybe the bonus of 1 point is just too small.
> 3) is less critical, but should be easy.
> 2) ... if I have typed at least 2 characters, filenames which actually contain
> that short string should always get a higher score than filenames which just
> contain those characters somewhere in their name.
>
> I could spend some time to work in this.
> With the behaviour as it is now, I'm often quicker using the file browser or
> "open documents" tabs.
>
> Comments ?
>
> Alex
>
>
>