Searching for operators has a bunch of unexpected edge cases:
The first colon : in the query is always treated as the separator for the type annotation => We can't search for the (:=) reference affectation!
Parenthesis and minus sign - are interpreted as a signal that the query is a type search (when the colon : separator is missing), to cover the common case where the colon was omitted... This doesn't work well when searching for an operator, for example (+) or >>- is a (type) parse error... unless one adds a trailing colon at the end of the query to disable the "smart" guess.
https://github.com/art-w/sherlodoc/pull/23 introduced a new edge-case as dots are stripped from the query, so e.g. searching for +. produces the same results as a search for +
I believe we could be a tiny bit smarter by checking the neighbors of the splitting characters to make operator searching more smooth :)
Searching for operators has a bunch of unexpected edge cases:
:in the query is always treated as the separator for the type annotation => We can't search for the(:=)reference affectation!-are interpreted as a signal that the query is a type search (when the colon:separator is missing), to cover the common case where the colon was omitted... This doesn't work well when searching for an operator, for example(+)or>>-is a (type) parse error... unless one adds a trailing colon at the end of the query to disable the "smart" guess.+.produces the same results as a search for+I believe we could be a tiny bit smarter by checking the neighbors of the splitting characters to make operator searching more smooth :)