--- In [email protected], "Sheri" <[EMAIL PROTECTED]> wrote: > > Yes, there are some issues with dot and CRLF but it's still an > improvement when you use anchored dots and multiline option. > > Try this: > > RegEx(esc("0r0n",0)++"abcdef"++esc("0r0n",0),?"(?m)^.+$", 1, 0, 0)
Yes, right. I already tested it. > BTW, This in my debug window: > > -1: -1 -1 > > Its to indicate no more matches? Right again. > Also, was it intended that nCount correspond to occurrence number? > I'm seeing "1:" before all the match offsets. It's the count of whole match and backreferences, i.e., for \0 and \1 ... \9. Try: pattern: (b)cd(e) & win.debug(ov[1],ov[2],ov[3],ov[4],ov[5],ov[6]) As you can see the array ov stores the start & end offsets of \0, \1, ... \9. BTW, the man page of PCRE says the size of ov should be the multiple of 3 (:if really so, should have used 30 instead of 20), however, I couldn't see the reason. It seemed to me multiple of 2 was enough. If 20 is not really enough, the above nCount will produce 0 which means that there is a match but the capacity of ov is not big enough to store the results. If that happens, try to replace 20 with 30. > But dot needs to match CRLF (twice) if (?s) option is in effect. > (Somewhere in the docs I saw that PCRE is deliberately treating CRLF > as two characters.) > > PS There are also times matching empty strings is useful. For > example, to count or replace the contents of empty lines specified > as ^$ It's funny. I thought exactly the same thing yesterday. However, empty match is evil if left as it is, because it'll be the gateway to the never ending story, infinite loop. And, if altered somehow, the output would not be as natural/expected. So, the user should find an alternative way, like in this case: (?<=\r\n|^)\r\n Sean
