Generated MS search lacks body_is_regex=1

[tripleee]

What problem has occurred? What issues has it caused?

When you create a PR from chat, SmokeDetector follows up with search results after a while. However, the generated search fails to specify that the search is for a regular expression. Thus e.g. #10227 has a search which could never work.

(It didn't work anyway for other reasons, but without the "regex" check box, it couldn't have.)

What would you like to happen/not happen?

The generated search should have the regex box ticked. That is,

MS search [here](https://metasmoke.erwaysoftware.com/search?utf8=%E2%9C%93&body=85275+87805%28%3F%23NO+NorAm%29)

should be

MS search [here](https://metasmoke.erwaysoftware.com/search?utf8=%E2%9C%93&body_is_regex=1&body=85275+87805%28%3F%23NO+NorAm%29)

[Andrew5057]

[field]_is_regex already gets added to website, keyword, and username watches/blacklists in gitmanager.py. Number watches/blacklists are the only exception. How common are comments for number blacklists? Would a hard-coded exception for (?# NO NorAm) be enough?

[Andrew5057]

Maybe we could just strip comments from number blacklists entirely. Something like item_to_search = regex.sub("\(\?#.*\)", "", item_to_blacklist)?

[makyen]

That regex is incorrect and will, potentially, strip things other than just comments. Please use the already existing regex to strip such comments. Actually searching for something that approximates what the phone number code does is substantially more involved than just stripping the comment and searching for the number. An approximation that's reasonably easy to code would be to use the same strategy as is used with the number search bookmarklets. Those don't attempt to handle potential obfuscations within the text. However, they do try to get at least some of those by also looking in the why data for the number, but the number showing up in the why data requires that it's already watched or blacklisted.