22160Re: A little help on look behinds
- Oct 16, 2011Flo wrote:
>I'd guess you're running this pattern in the (Ctrl+R) dialog box instead of in a clip -- where it's meant to ***capture or fail*** only once (on the very first instance of either [[[ or ]]]).
> --- In firstname.lastname@example.org, Sheri <silvermoonwoman@> wrote:
> > (*COMMIT) says the rest of the pattern must match from here without
> > backtracking...I guess you could say it creates an anchor in
> > the middle of the pattern.
> I would be grateful for some more explanations about that verb '(*COMMIT).
> I've tested your clip...
> against the following text which is quite similar to John's first sample. For our discussion, I've added line numbers (to be removed when testing):
> 1 First line
> 3 [valid line]
> 5 ]]] remove
> 7 ]]] remove
> 9 [[[ valid line
> 10 more valid lines
> 11 ]]] valid line.
> 13 [[[ valid line
> It's quite clear for me why the clip removes line #5 and #7 but not #9. But I still can't see why it doesn't remove line #11.
> If we omit the '\K' we can see two matches:
> - 1. from start of string to end of line #5
> - 2. line #6 till end of line #7
> Next, line #8 and #9 are not matched because line #9 doesn't start with ']]]'.
> But WHY doesn't the clip jump over that mismatch and moves on selecting line #10 and #11? IMHO, line #10 should be matched with '(?s)\A.+?\R\K(?=\]\]\]|\[\[\[)' (with or without '\A'), and the following '(?-s)\]\]\].*\R'. Why on earth is '(*COMMIT)' preventing this?
> Thanks for any light you can shed on this!
If you click "Find Next" after #5 and #7, notice that your beginning position for the next attempt is on or after line #7. After the first available alternative "[[[" is spotted by the look-ahead now on line #9, (*COMMIT) demands that at this very location either "]]]" should be found or else the whole pattern should abandon any further matching attempts. Obviously, "[[[" ain't the required "]]]" so the pattern fails by design.
- << Previous post in topic Next post in topic >>