22594RE: [Clip] Re: FIND in NTL V7pr3 still acting odd
- Apr 13 4:55 PMI have one of the largest regex libraries of anyone � it's 15,000 lines of code in size, not counting comments. It runs
just fine on v7. The only problem I experienced was a couple programming errors that 6.2 ignored, but v7 caught. That is
a good thing.
\R is included in \s, so you need no \R if you have \s present. You will never capture a \R following a \s, because the
\s will capture it first. FYI - \R includes all forms of carriage returns, DOS/Windows/Mac/Unix, and \s includes all of
those plus all spaces, tabs, etc.
RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of joy8388608
Sent: Friday, April 13, 2012 16:30
Subject: [Clip] Re: FIND in NTL V7pr3 still acting odd
--- In email@example.com <mailto:ntb-clips%40yahoogroups.com> , "flo.gehrke" <flo.gehrke@...> wrote:
> --- In firstname.lastname@example.org <mailto:ntb-clips%40yahoogroups.com> , "joy8388608" <mycroftj@> wrote:
> > Part of my clip selects groups of lines from the start of a line
> > containing a name up to a blank line. So starting on the first
> > line of the sample data below, it selects from MORSE up to and
> > including the empty line before CLEMSON.
> > In V6.2, a non-clip FIND using (?s).+?(\R\s*\R|\z) does this and
> > the two clip lines below (Jump and Find) work in the clip.
> > In version 7pr3, it selects all the way to the end of the document.
> The problem seems to be in the alternation '(\R\s*\R|\z)'. You can see the difference when testing this subpattern
> In NT6, the first alternative '\R\s*\R' matches the two CRNL at the end of each block. So, with each iteration,
'(?s).+?(\R\s*\R|\z)' matches a single block followed by an empty line, or at end of string.
> In NT7, '\R\s*\R' is always false. So the whole string from start to end is completely matched by the second
> I can't find an explanation for that different behavior in the PCRE Changelog. So it might be worth looking after
> Possibly, NT7 has a problem with '\s*'. It works with '(?s).+?(\R(\s)*\R|\z)' in both NT6 and NT7. Also replacing
'\s*' with '\W*', for example, could be a work-around.
> > In 7pr3, ^= finds the first '=' on a line, but F3 (Find Next)
> > finds and selects the second '=' on the line, then the third, etc.
> I can't reproduce this in NT7. '^=' matches the first '=' in a line only. Pressing F3 doesn't match a '=' on the
second or any following position in the line (or paragraph).
Eb and Flo,
Thank you so much for looking into this and giving me a fix for my clip. Both the (\s) and \W solutions work. Thanks
also for showing me I'm not starting to imagine things.
I'm relatively new to Reg Exps, and don't see why '\R\s*\R' should always be false. New line followed by a line
containing only option white space makes sense to me...
I reinstalled V7pr3 (thank goodness the process is quick and easy) and it is STILL doing the thing with the '='. Also, I
opened a clip library and did a search for 'find'. Find Next jumps from 'find' to 'find' selecting each as it is found
(and only selecting those four letters even if it encounters a word such as 'finding'). This is all correct. BUT...
every so often it will encounter 'find' and highlight 'ind ' or encounter 'finds' and highlight the 'inds'. It seems to
happen on the first match after it (automatically) moves to the next clip. In other words, the first match in each new
clip within the library.
Is anything EXPECTED to no longer work the same way in either the update to V7 or with the new PCRE? I seem to be
wonderful at stumbling on to stuff like that.
[Non-text portions of this message have been removed]
- << Previous post in topic Next post in topic >>