59ccfe5918
While implementing the overdue search, I realised it would be nice to be able to construct a search string with OR and NOT searches without having to construct each part individually with build_search_string(). Changes: - Extends SearchTerm to support a text search, which will be parsed by the backend. This allows us to do things like wrap text in a group or NOT node. - Because SearchTerm->Node conversion can now fail with a parsing error, it's switched over to TryFrom - Switch concatenate_searches and replace_search_term to use SearchTerms, so that they too don't require separate string building steps. - Remove the unused normalize_search() - Remove negate_search, as this is now an operation on a Node, and users can wrap their search in SearchTerm(negated=...) - Remove the match_any and negate args from build_search_string Having done all this work, I've just realised that perhaps the original JSON idea was more feasible than I first thought - if we wrote it out to a string and re-parsed it, we would be able to leverage the existing checks that occur at parsing stage. |
||
|---|---|---|
| .. | ||
| cargo | ||
| .gitignore | ||
| BUILD.bazel | ||
| build.rs | ||
| Cargo.toml | ||
| lib.rs | ||