Open geofurb opened 4 years ago
We use fuzzy search, which includes results which don't match exactly. It does look like it prefers shorter strings in our current usage, given your example.
Can you talk a little bit about why you'd like non-exact search results to be removed entirely? We do expect them to be useful when typing quickly, or when your text has basic typos, or even when you don't know the exact spelling.
Non-exact search results often appear before the exact results, and results are not prioritized according to the user's frequency-of-use. This is a frustrating behavior, as some emoji cannot be reached without triggering fuzzy detection for several other results, and the user has no easy way to get to the desired emoji. This feature can make the interface quite cumbersome.
It's fine to keep non-exact matches, but as previously mentioned, the better matches should appear first. In case the origin of the bug is still unknown, I checked the example on the library used, and the library sorts the matches correctly (meaning that :rolling... appears before :drooling...). So the bug does not come from library, but from Signal-Desktop use of the results from the library.
Steps to reproduce:
Using https://fusejs.io/demo.html with:
list.json
[
{
"emoji": "flag_ae",
},
{
"emoji": "pirate",
},
{
"emoji": "rolling_on_the_floor_laughing",
},
{
"emoji": "drooling_face",
},
{
"emoji": "face_with_rolling_eyes",
},
{
"emoji": "sweat_smile",
},
{
"emoji": "sweat",
},
]
main.js
const options = {
// isCaseSensitive: false,
includeScore: true,
shouldSort: true,
// includeMatches: false,
// findAllMatches: false,
// minMatchCharLength: 1,
// location: 0,
// threshold: 0.6,
// distance: 100,
// useExtendedSearch: false,
// ignoreLocation: false,
// ignoreFieldNorm: false,
keys: [
"emoji"
]
};
const fuse = new Fuse(list, options);
// Change the pattern
const pattern = "rolling"
return fuse.search(pattern)
results:
[
{
"item": {
"emoji": "rolling_on_the_floor_laughing"
},
"refIndex": 2,
"score": 0.001
},
{
"item": {
"emoji": "face_with_rolling_eyes"
},
"refIndex": 4,
"score": 0.1
},
{
"item": {
"emoji": "drooling_face"
},
"refIndex": 3,
"score": 0.15285714285714286
}
]
Lower score means better match, meaning that rolling_... should come first, as it does in the output of the library when using the shouldSort
option.
@hiqua Thanks for this analysis. It looks like fuse sorts in an unexpected order. You can expect change soon in how Desktop uses fuse search results.
@scottnonnenberg-signal should we try to implement a fix? Or is it on your roadmap already?
@hiqua You're welcome to play with the fuse settings, but with fuzzy search you may very well cause another odd search result, or make search harder to use.
Seems like there's a further issue here. When typing an emoji and you have any capital letters, it will not autocomplete upon hitting enter. Literally nothing happens, the text stays the same.
That's another issue: https://github.com/signalapp/Signal-Desktop/issues/5018 For which there is already a PR: https://github.com/signalapp/Signal-Desktop/pull/5186
Bug Description
Emoji prediction does not follow spelling precisely in the Signal for Desktop client. (Tested on Windows 10.)
Steps to Reproduce
Actual Result:
Emoji predictions begin with ":drooling_face:" (🤤)
Expected Result:
Emoji predictions should include only emoji with "rolling" in their text. (e.g. ":rolling_on_the_floor_laughing:" (🤣) and ":face_wtih_rolling_eyes:" (🙄).
Screenshots
Platform Info
Signal Version:
v1.33.4
Operating System:
Windows 10 (10.0.18363)
Linked Device Version:
4.58.5