After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 688772 - Partial matches are scored higher than exact matches
Partial matches are scored higher than exact matches
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File Search Interface
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-21 00:36 UTC by erusan
Modified: 2013-04-05 00:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
file: do not reverse collated order for files with same search rank (1.10 KB, patch)
2013-04-05 00:19 UTC, Cosimo Cecchi
committed Details | Review
query: rank prefix matches lower than exact matches (1.60 KB, patch)
2013-04-05 00:19 UTC, Cosimo Cecchi
committed Details | Review
search-hit: add a missing break (802 bytes, patch)
2013-04-05 00:19 UTC, Cosimo Cecchi
committed Details | Review

Description erusan 2012-11-21 00:36:11 UTC
Steps to reproduce:
1) In any folder, enter search parameter
2) Uncheck "reversed order" from the dropdown
3) Alter search parameters in any way -- the search has now reset to reversed order
Comment 1 António Fernandes 2013-01-27 22:21:32 UTC
Nautilus search results are sorted by search relevance. Relevance must be in descending order ( = most relevant result first).

"Reverse order" means "descending order" when sorting numbers. I must agree this use of "Reverse order" is misleading when talking about Relevance. But "Descending order" would make no sense in the context of alphabetic sorting.

Anyway, I don't see any use case for ascending relevance order ( = least relevant result first). In my opinion, the "Reverse order" option should be disabled and hidden when items are sorted by relevance.
Comment 2 erusan 2013-01-27 22:33:04 UTC
What I am speaking about is the sorting where longer filenames are listed before shorter filenames.

Create a folder with 3 files in it: 'me', 'meme', and 'mememe'.
Now search in that folder or "me".
The first result is 'mememe'. This is counter-intuitive and also contrary to the behavior of every other file manager.

When I search for "me", I want 'me' to show up first.

If I am searching for "document1", would I want "document198942" to show up first, or "document1"?
If I am searching for a picture and type "frank", why would I want "FrankZee.jpg" to show up before simply "Frank.jpg"?
Comment 3 António Fernandes 2013-01-27 22:52:09 UTC
Thanks for quick feedback.

I see what you mean and I can reproduce it here. I think your expectations are right. Exact matches should be scored higher than partial matches (modulo file format extension).

I'll rename the title of this report to reflect this.
Comment 4 Cosimo Cecchi 2013-04-05 00:19:43 UTC
There were indeed bugs in how results were ranked in those cases.
I pushed some fixes for this to git master now, thanks for the report.

The following fixes have been pushed:
dd8f341 file: do not reverse collated order for files with same search rank
9f2d8a5 query: rank prefix matches lower than exact matches
e55a3fe search-hit: add a missing break
Comment 5 Cosimo Cecchi 2013-04-05 00:19:46 UTC
Created attachment 240674 [details] [review]
file: do not reverse collated order for files with same search rank

When two search results rank equally, we fall back to the collated
order.
Since search is usually ranked reversed (highest at the top), we need to
ensure we don't accidentally reverse the collated order as well.
Comment 6 Cosimo Cecchi 2013-04-05 00:19:49 UTC
Created attachment 240675 [details] [review]
query: rank prefix matches lower than exact matches

Count how many letters are left after the string occurrence, and
subtract that from the match score.
Comment 7 Cosimo Cecchi 2013-04-05 00:19:53 UTC
Created attachment 240676 [details] [review]
search-hit: add a missing break