Skip to content

Fix minor search parser issues

Created by: rvantonder

I discovered some syntax that is not interpreted correctly that I should fix, in the interest of migrating the parser for 3.20:

  • (search\() => This should search for search\( in regex mode. But, we have a heuristic that checks for () at the end and treats it literally, but this heuristic is too naive, and doesn't recognize the escape character. It needs to. #13803

  • Search()\( => In regex mode, this is parsed as (concat "Search" "()" "\\("), but should be contiguous. The reason it is parsed as concat is because the () in the middle splits the pattern as we scan, it's a mix of issues about heuristics, and not checking explicitly for whitespace. Either something like whitespaceSeen during the loop could work, or modifying the concatPatttern to just concat contiguous patterns based on range. The reported range for () is also wrong, look at the response in the API console. The () is start: 7 end 8, should be start 6 and end 8. But for something like Search(x)\( API console, or Search(blahblah)\(, we actually remove the (...) because the scanner/parser thinks it's a group and not a contiguous pattern. So we won't be able to just merge contiguous patterns based on range for this--the (...)s are removed. Question: why doesn't this just succeed for parsePattern? Should we trigger parsePattern before matching a ( and doing parseOr? side note: an example where this leads to wrong fuzzy searches are Searc(h)\( and Search()\(. Maybe just checking for escaped ( in balancedSearchPattern works. #13432

  • \(\) => In literal mode, this is labeled as dangling paren, which is basically just nonsense and should not be labeled.

  • #13355 (file:"thing with a space") => A valid parameter with a quoted value should be interpreted as such. Currently, the scanner that looks for values inside a potential group bails out when it sees a space, and will treat this pattern literally in literal mode, and as a search pattern file:"thing with a space" in regex mode. In both cases, it should recognize this form as a group with a single, valid search parameter, by taking into account possible quoting

  • #13404 /regex/ is labeled as literal

  • Refactor: Get rid of literal_parser.go and merge the scanner functions, passing in functions for the logic where they differ. #13754 (closed)