How does KDevelop's quick open match names??

[Matthew Woehlke]

Okay, this has been bothering me for some time. Can someone explain the
logic behind how Quick Open decides what it thinks you want to open? In
particular, can someone explain why it "prefers" more distant matches,
at least when typing file names?

See attached example. I've typed "options.p", which Quick Open thinks is
a better match for "options_for_QT.cpp", which is a "split" match (if I
divide the input string into three parts, each part matches, in order)
than for "make_options.py", an exact substring match.

I notice this almost constantly; given an input like "abc", Quick Open
almost always "prefers" matches like "qabdcx" (that only match when
additional text is inserted e.g. between 'b' and 'c') over a match like
"abc.x" that not only contains, but *starts with*, the exact string
"abc". Why is this?

[Sven Brauch]

Hi,

Post by Matthew Woehlke
Okay, this has been bothering me for some time. Can someone explain the
logic behind how Quick Open decides what it thinks you want to open? In
particular, can someone explain why it "prefers" more distant matches,
at least when typing file names?

This is a known usability issue. As far as I know, the reason for it is that
there is "fuzzy" matching of entries, but no sorting by "fuzziness", instead
matched entries are always sorted alphabetically.

Best,
Sven

[René J.V. Bertin]

On Saturday July 21 2018 08:50:31 Sven Brauch wrote:

Hi,

Post by Sven Brauch
there is "fuzzy" matching of entries, but no sorting by "fuzziness", instead
matched entries are always sorted alphabetically.

That shouldn't be hard to fix, provided the matching algorithm gives a "closeness" score that makes sense (to the user).

[Milian Wolff]

Post by Matthew Woehlke
Okay, this has been bothering me for some time. Can someone explain the
logic behind how Quick Open decides what it thinks you want to open? In
particular, can someone explain why it "prefers" more distant matches,
at least when typing file names?
See attached example. I've typed "options.p", which Quick Open thinks is
a better match for "options_for_QT.cpp", which is a "split" match (if I
divide the input string into three parts, each part matches, in order)
than for "make_options.py", an exact substring match.
I notice this almost constantly; given an input like "abc", Quick Open
almost always "prefers" matches like "qabdcx" (that only match when
additional text is inserted e.g. between 'b' and 'c') over a match like
"abc.x" that not only contains, but *starts with*, the exact string
"abc". Why is this?

I've worked on this "recently". Fixing your situation should certainly be
possible. I think it behaves as-is simply because we developers weren't
bothered by this specific quirk yet. Personally, I hacked the quickopen
matching algorithm a couple of months ago only because the path/file naming
convention in a new project I was working on triggered some corner cases I
didn't see before. I think your case is another such case.

Note that the quickopen code base is very well unit tested. Meaning: try to
look at the unit tests, extend the code to add a (failing) test for your
situation. Then either also start to change the code to fix the test, or at
least send in this new unit test code to quickstart the work for others (me?).

Cheers

[Matthew Woehlke]

Post by Milian Wolff
Note that the quickopen code base is very well unit tested. Meaning: try to
look at the unit tests, extend the code to add a (failing) test for your
situation. Then either also start to change the code to fix the test, or at
least send in this new unit test code to quickstart the work for others (me?).

I took a quick look, but it isn't immediately obvious how the test code
works. (Maybe I'll take a longer look later.)

Meanwhile, I think a simple test would be to do a look-up for "foo" on
the list "a/foo.cpp", "a/bar.cpp", "a/farboo.cpp". IIUC, the current
behavior will select "a/farboo.cpp" as the 'top' match (because it *is*
a match, and it sorts lexicographically before "a/foo.cpp"), even though
the user more likely wanted the latter.