Welcome to the IDM Forum. This forum is meant as a user-to-user support mechanism where users can share knowledge and tips for all IDM software.
Since these forums are user-to-user based, IDM does not regularly read or reply to the posts in this forum. For problem reports, suggestions, or feature requests, you must email us directly. Our trained technical support staff answers most inquiries within 30 minutes.
mjcarman wrote:I don't believe that UE does line-by-line matching. If that were true, it wouldn't be possible to match text that spans lines. That said, UE does have some issues with lookaround adjacent to newlines. Send a bug report to IDM, and don't use them (for now).
mjcarman wrote:There are better ways to anchor at/after the beginning of a line:
mjcarman wrote:A "." matches any character except newline. That's not a bug; it's Perl regex syntax. Perl contains a modifier (/s) to make it match newlines too but UE doesn't provide a way to set it.
Bracket wrote:I got [the line-by-line] info from IDM support directly, and it's proven true by the test I showed above. And it is possible to match text that spans lines with line-by-line parsing - the RegEx is only applied to one string at a time, but UE is managing the handling, so they're basically jury rigging multi line support.
Bracket wrote:I was only using [the look-around anchors] as an example.
Bracket wrote:"(?s)" is what enables [the "." matches newline] option for the regex that follows it
mjcarman wrote:The "[^ÿ]" and "(?:.|\r\n)" were workarounds for the lack of a way to set the /s modifier. As Bracket figured out we can use the inline (?:s) modifier; the workarounds aren't necessary.
mjcarman wrote:Greedy quantifiers become non-greedy when the quantified item can span multiple lines. (e.g. "(?s).*" effectively becomes "(?s).*?"
mjcarman wrote:There doesn't appear to be any way to get UE to apply the regex to the entire file at once. This means that:
\A and \Z won't work
mjcarman wrote:Look-around by the start/end of lines won't work
mjcarman wrote:I doubt that this is a limitation of the Boost library API. I suspect it's a deliberate decision to improve performance and make behavior more intuitive for typical end users. Bracket won't like me saying this, but it was probably the right decision. The problems we're seeing are corner cases.
Bracket wrote:From what I understand, EditPad Pro has complete Regex support and does not suffer at all as a result of it.
Start matching from here
Next possible (and correct) match