Hi, @mark-olson and All,
Oh…, my God : you’re a thousand times right, Mark ! Of course, negative class character like [^...] does not depend at all on the status of the . matches newline option, nor of the possible leading modifiers (?s) and (?-s). I should have remembered that !
Indeed, place this simple text in a new tab :
Test in order to verify the maximum range of characters matched by the regex expressionAnd use, for example, any of the regexes below :
With the . matches newline option unchecked
- SEARCH [^=]+.+[^=]+ - SEARCH (?-s)[^=]+.+[^=]+ - SEARCH (?s)[^=]+.+[^=]+With the . matches newline option checked
- SEARCH [^=]+.+[^=]+ - SEARCH (?-s)[^=]+.+[^=]+ - SEARCH (?s)[^=]+.+[^=]+You can easily verify that, whatever the regex used, all text, from the very beginning to its very end, is always matched !
Remark :
In fact, as the in-line modifiers override the . matches newline option, there are only four distinct cases :
SEARCH [^=]+.+[^=]+ with the . matches newline option unchecked
SEARCH [^=]+.+[^=]+ with the . matches newline option checked
SEARCH (?-s)[^=]+.+[^=]+
SEARCH (?s)[^=]+.+[^=]+
Thus, in my previous post, I should have expressed myself :
May be, the fact, that a negative class character is used ( [^ ...] syntax ), led to the The complexity… message ??
Best Regards,
guy038