@gparyani I'm not against having some easily recognized visual indicator that MS thinks the feedback is for the most recent post. However, the specific proposal doesn't fit all parameters, as it would require changes to FIRE. I'm not against that, but it is potentially significant additional work.
FIRE bases everything (including substantial internal data structures) off of the URL/UID for the SE post, not the MS post ID. For feedback messages, that URL/UID is only available/derived from the URL used for the SE link in the post's title. The MS post ID is not something which is available on SD reports, so can't be used. In fact, it's non-trivial to accurately match up SD reports to MS post IDs in all cases (i.e. when there's more than one MS post for an SE post).
It is, of course, possible to use just the MS post ID. If it was available on SD reports (not possible without delaying posting reports into chat in order to get a response from MS to the creation of the new report), it would be preferable.
So, overall, not having the URL from a link to the SE post would make the changes necessary in FIRE substantially more complex. OTOH, personally, I feel having a FIRE button on the feedback for the most recent report is a bit redundant.
@Yatin (cc @Xnero) The regex input on regex101 assumes that the text being entered for the regex is as it is represented in source code for that language/regex type and that the representation is in the format which regex101 is displaying, including the greyed-out delimiters (selectable for the PCRE regexes) which are shown to the left and right of the regex.
The assumption that these delimiters are being used makes it such that additional backslash-quoting of some characters, particularly the forward slash, is required on regex101, but isn't needed in a watch/blacklist for SD or on MS, which are both using the input as a text string, not representing that text string in code. However, including that additional backslash-quoting in a watch or MS regex search doesn't result in any errors or differences in operation.
So, for some regexes in the watchlist you'll find that the extra backslash-quoting has been left in, but merely as a convenience when copy-and-pasting to/from the blacklist/watchlist and regex101, and/or MS (which has its own requirements for backslash-quoting).
An alternative for regex101, when specifying a PCRE regex, is to select a different delimiter to use. However, doing so, of course, makes it necessary to backslash-quote whatever alternate character you've selected as the delimiter, if that alternate delimiter is used in that regex.
@Yatin (cc: @Xnero @AndrewT.) In that regex, the (?![\W\w]*?</(?:code|blockquote)>) at the end of the regex doesn't permit a match in strings which contain a </code> or </blockquote>, which makes the regex not match any body text where the user has included any code or a blockquote, as having either of those tends to make it more likely that it's FP.
@Xnero (cc: as above) The regexes which are used for SD test against the (somewhat modified) HTML which SE has converted the Markdown into. They do not currently test against the Markdown. Testing against the HTML has both benefits (each regex doesn't have to account for both HTML and Markdown, which would make many of them substantially more complex) and drawbacks (malformed HTML is stripped by SE, so SD doesn't even see some things, which it could detect, that are only in the Markdown).
@Xnero There are substantial differences between the Markdown and the HTML provided by SE, and between that and what the SD regexes test against. While it's reasonable to colloquially refer to just "in the Markdown", there are times when doing so is insufficient or inaccurate.
For the specific discussion I was replying to, which was explicitly about a regex detecting </code> and </blockquote> tags, there is a notable difference. It's also unclear from the discussion that, at the time the original question was asked, the participants understood that the (?:code|blockquote) was looking for HTML tags, rather than just those words in the text.
In addition, the the full conversation did not make it clear that there that understanding had been reached by the end of the conversation. Thus, it felt reasonable to clear up any possible lingering ambiguities.
user435118
6:20 PM
@Makyen "...which are both using the input as a text string, not representing that text string in code" - but what regex is the text string being tested against then?
In Python, text strings which are intended to represent the regex text are typically entered as r"Your rexex text here", which is what regex101 assumes. If represented in that format, then you can't have a double-quote character, ", in the string without backslash-quoting it (ignoring that Python allows you to use alternate string delimiters, which would change the character or sequence which needs to be backslash-quoted).
For SD, all of the regex-based watch and blacklist files are read in as straight text. They are not read in as Python code. Thus, there's no need to worry about double-quotes being used as delimiters to indicate strings, and no need to quote a non-existent delimiter.
The file format does use delimiters, with each regex on a different line, with each entry separated by the representation of a new line. So, you still have to avoid inclusion of a newline (or the sequence representing a new line) in a regex in order for the text file to be properly read in.
However, representing a new line in a regex is a universal issue, so there's "normal" ways to do so that are similar in basically all regex flavors. Thus, it's not something which is thought about in the same way, because it's something which is done similarly in most regex flavors and doesn't mess people up (as much) when switching between regex flavors.
Similar to how the watch/blacklist text files are read in as text, regexes on MS are entered in an <input type="text"> element without any start of regex or end of regex delimiters. Thus, there's no need to backslash-quote a character which is being used as such a delimiter.
teward/Osiris: In getting MS post information, recovered from requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='metasmoke.erwaysoftware.com', port=443): Read timed out. (read timeout=10.0)
