staktrace / query-parser

A search query parser
6 stars 2 forks source link

Should there be special casing to recognize `Class::method` as a single term with value "Class::method" instead of with key "Class:" and value ":method"? #1

Closed asutherland closed 2 years ago

asutherland commented 2 years ago

Right now Class::method (without any quotes as part of the actual query string) parses as key="Class:" and value ":method" as the following assertion checks when added locally:

assert_eq!(parse("Class::method").terms, &[Term::new(false, Some("Class"), ":method")]);

(Extra context that @staktrace already knows but others reading along might not) I raise the question because for https://bugzilla.mozilla.org/show_bug.cgi?id=1762817 the existing (ad hoc, manual) search syntax will treat "Class::method" just as a term with value "Class::method" and in my attempt to allow richer querying using query-parser, this constitutes a regression.

I think the answer is probably just that people should quote things in this case for the purposes of sanity, but it is an interesting question since arguably the situations can be differentiated.

staktrace commented 2 years ago

I don't think I would want to special-case this by default, but we could probably add something to the ParseOptions that handles the double-semicolon specially and treats it as a term with just a value.

That being said, my inclination is more to accept the regression and resolve it via user education - one of the things I had in mind when writing this library was that it should be easy to present the parsed/structured query back to the user so they can see exactly how we're interpreting it (similar to how Wolfram Alpha will take a natural language query and show you an "input interpretation"). So in this case the input interpretation would show the user that's being parsed in an unintended way and they would (hopefully) realize that they need to enclose it in quotes to have it parse the way they expect. Thoughts?

asutherland commented 2 years ago

I agree that user-education and having searchfox explain what it's doing probably is the right solution as opposed to starting a journey of a million one-off hacks. Also, at least I personally use keyword bookmarks for most searchfox purposes right now, and arguably searchfox could have more of an "onboarding" page that could suggest potentially adding a distinct keyword bookmark that automatically quotes its payload for the common case so that it's not a rake that people are constantly stepping on. (Although there are muscle-memory trade-offs with that approach, of course.)

And if an awesomebar webextension gets added, it could maybe have its own heuristic to help the user automatically quote in this case via a push-tab upsell or something like that.

I'll mark this closed then since I think we're on the same page and no action should be taken in this repo. Thanks for the quick response!