Re: fuzzy-matching in quickopen...

On 2022-09-16 16:25, Waqar Ahmed wrote:
> 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.

The question is, if some people liked the very old behavior of 
preferences for
open files, if somebody provides a patch to make this configurable via 
the
context menu (as we have already for the project scope), I think that 
would be
acceptable.

A config option in the context menu is non-intrusive and will IMHO
annoy nobody.

Not that I would now start to add there a lot fine tuning options
that nobody understands.

Greetings
Christoph

> 
> On Fri, Sep 16, 2022 at 3:11 AM Alexander Neundorf <[email protected]> 
> 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
>> 
>> 
>> 

-- 
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org