Configure maxEditDistance and maxSequentialEdits for fuzzy searches

The current values for the maxEditDistance (4) and maxSequentialEdits (1) arguments of the FuzzyMatchQueryPart constructor as used in QueryParser.CreateWordQueryPart() yield too many results that are nothing like the search term for my taste - especially for short search terms.

E.g. if I search an English text for ?term with maxEditDistance = 4 I get matches like very, here, were or seems which occur quite often - creating a lot of noise in the search result.

It would be nice to have a way of configuring those values

1. on a FullTextIndex level via the FullTextIndexBuilder using something like .WithQueryParser(o => o.FuzzyMaxEditDistance(2).FuzzyMaxSequentialEdits(0))

2. on a Query level 2.1 by either intercepting the query parsing using some hook, e.g. .WithQueryParser(o => o.FuzzyMaxEditDistance(someContext => 2).FuzzyMaxSequentialEdits(someContext => 0)) 2.2 and/or by supplying the values with the query (similar to the nearness syntax), e.g. 2.2.1 ?2,0term (both integers comma-separated after the ? with the first int being maxEditDistance and the second one maxSequentialEdits) or 2.2.2 2?0term or 2?term or ?0term (maxEditDistance before the ? and maxSequentialEdits after)

3. dynamically based on the length of the search term to account for shorter words, e.g.

.WithQueryParser(o => o
     // a maximum of a fourth of the letters may differ
    .FuzzyMaxEditDistance(termLength => termLength / 4)
     // with a maximum of a tenth of the letters edited in sequence
    .FuzzyMaxSequentialEdits(termLength => termLength / 10))

---

Do you have any plans for implementing something like this - one way or the other? Please consider my syntax suggestions above as just that; I’m not opinionated on them. I only wanted to get across how I’d like to use the API to get fewer results while expanding on the existing API where I would expect it.

Thank you for your work and compliments on the API design and documentation! This library is exceptionally easy to use for its complexity.

[h0lg]

In version 3.4

• the query syntax now works as I would have expected it without reading the manual and
• the default calculation for max sequential edits works better for short fuzzy search terms.

Also, the doco links work again 😃

Thanks a bunch ❤️

[mikegoatly]

Thanks for the feedback! This code commit and docs commit should address all of these points .

• The query syntax to support the comma being omitted, i.e. ?2?term will be allowed.
• The default calculation for max sequential edits will change from termLength / 4 to termLength < 4 ? 1 : termLength / 4 - yes this was an unintended consequence of the change! 😃
• All the docs have been updated and links fixed