Nice, I can confirm this variant is working, even with quantifier limits far above 256(!?).
I had thought that something with the OR might be causing it, so even tried ([\s\S]) (whitespace or non-whitespace) instead of the (.|[\r\n]) but that didn't work either - no idea what the regex engine is doing internally here.
It seems like it makes a difference wether there is a capture group around the quantified part or not.
The expression
dotall:regex:asciicontent:"onMessage.{1,700}a"
finds
655 files.
The expression
dotall:regex:asciicontent:"onMessage(.){1,700}a"
finds only
31 files.
They should be equivalent under regex semantics. Is the capture group causing the regex engine to compile it differently and require recursion? Is there some other limit of the engine (like limit of found capture groups)? Using a non-capture group (?:.) doesn't seem to change anything.
Not sure what nonsense the regex engine is doing here. Linear-time recursion-free regex engines like
https://github.com/google/re2/wiki/WhyRE2 exist, but i think that only supports actually-mathematically-"regular" regular expressions, e.g. no backreferences/look-arounds possible.
Its completely reasonable if you judge this to be unviable/too niche to deserve further attention/fixing.
I think some sort of warning to the user in case the regex search hit a limit is needed though, especially for cases where a limit-reaching regex returns *some* results (the ones that were found without hitting the limit?) but not all, as that would give false conficence of having searched properly.
Thanks!