o0101
commented
2 years ago @jeancroy this is good too, and it's up to you what you do with your library, but personally I'm concerned it would add a lot of complexity to the implementation, and I wouldn't want to see you bogged down in this at the expense of the core stuff. And I see the core stuff as fuzzy search.
Sometime it's good to be a little less fuzzy.
Filters: Prune results using a custom function. Example use case is to filter by a status code. Must be done before spending time on computing fuzzy score, must also preserve cache.
"literal expression": Remove the literal word from the fuzzy search, but build a filter that require it to be present as-is in one of the field (case insensitive indexOf). Let the highlighter be aware of this and act accordingly.field: "literal expression": Same, but must exist in this particular field. (see tagged search)literal field: Use case is for date / status code. A match is not required. But for this field to contribute to the score, one of the query word must be present (case insensitive indexOf). Does not require usage of "literal" although it should respect it (for example "multi word"). Let the highlighter be aware of this and act accordingly.
#word,@word: For all use case this syntactic sugar over thetag:syntax. Difference is that it may happen in the middle of a query, and is limited to a single word.