Loading ...
Sorry, an error occurred while loading the content.

22594RE: [Clip] Re: FIND in NTL V7pr3 still acting odd

Expand Messages
  • John Shotsky
    Apr 13 4:55 PM
    • 0 Attachment
      I 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.

      Regards,
      John
      RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/

      From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of joy8388608
      Sent: Friday, April 13, 2012 16:30
      To: ntb-clips@yahoogroups.com
      Subject: [Clip] Re: FIND in NTL V7pr3 still acting odd




      --- In ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com> , "flo.gehrke" <flo.gehrke@...> wrote:
      >
      > --- In ntb-clips@yahoogroups.com <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.
      >
      > Joy,
      >
      > The problem seems to be in the alternation '(\R\s*\R|\z)'. You can see the difference when testing this subpattern
      only.
      >
      > 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
      alternative '(?s).+?\z'.
      >
      > I can't find an explanation for that different behavior in the PCRE Changelog. So it might be worth looking after
      that.
      >
      > 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).
      >
      > Regards,
      > Flo
      >

      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.

      Thanks again,
      Joy



      [Non-text portions of this message have been removed]
    • Show all 15 messages in this topic