GNOME Bugzilla – Bug 693935
search: Simplify and correct behavior for substring searches
Last modified: 2013-02-16 18:24:42 UTC
According to Cosimo, we should expect like search providers join the terms, and care about order. Thus, we can't expect that an addition to any of the terms is a subsearch.
Created attachment 236343 [details] [review] search: Simplify and correct behavior for substring searches Early on, search was based on a list of terms, which was like a set of tags, in that terms were OR'd, and that order didn't matter. As such, modifying any one of the terms wouldn't produce new results. Nowadays, providers take the order into account, so a substring should only be the case if new terms are added to the end.
Review of attachment 236343 [details] [review]: I think this is generally the correct thing to do, one comment below. ::: js/ui/search.js @@ +70,3 @@ let previousResultsArr = this._previousResults; + let isSubSearch = false; + if (previousResultsArr.length > 0) I don't think this condition check is optimal - previous code had the value of isSubSearch only depending on the terms and not the results. How about changing this to this._previousTerms.length?
Created attachment 236380 [details] [review] search: Simplify and correct behavior for substring searches Early on, search was based on a list of terms, which was like a set of tags, in that terms were OR'd, and that order didn't matter. As such, modifying any one of the terms wouldn't produce new results. Nowadays, providers take the order into account, so a substring should only be the case if new terms are added to the end.
Review of attachment 236380 [details] [review]: Looks good to me
Attachment 236380 [details] pushed as b292bba - search: Simplify and correct behavior for substring searches