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

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

Expand Messages
  • joy8388608
    Apr 14, 2012
    • 0 Attachment
      Wow, I think I actually understand enough about this to answer the question...

      If the \s matches NLs and is greedy, it should never match anything ending with \R since the match to \R would already have been eaten by the \s. This is not always happening so something is goofy.

      As a reminder, isn't anyone interested in all the problems I reported about FIND? I've reported three different issues so far and my reports just seem to keep falling into never-land. It makes no sense that everything works fine for me and I have these intermittent issues with V7. I've been doing this long enough to have a good feel for this type of thing and I'd put money on the fact that there is a problem here... there just are not enough people doing the things I'm doing or REPORTING the problems they see IF they, in fact, even notice them. When the wrong characters are selected during a find, this will obviously affect clips that use what is selected after a find. I know I did not test to see if what is selected on my screen is actually what NT THINKs is selected, but that's not the point.

      Of course, if someone IS looking into this, it would be nice to be told so I don't bring up issues that are already being addressed.

      Thanks, everyone. I know I've said it before, but the people on this group are very nice.

      Joy



      --- In ntb-clips@yahoogroups.com, "John Shotsky" <jshotsky@...> wrote:
      >
      > HmmmÂ…I'm not sure I understand the argument. All I said is that if \s* precedes a \R, the \R would never capture
      > anything, because the \s would capture any following contiguous whitespace. If you are saying that is not true, I can't
      > see why it would not be true.
      >
      > 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 flo.gehrke
      > Sent: Saturday, April 14, 2012 04:19
      > 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> , "John Shotsky" <jshotsky@> wrote:
      > >
      > > \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.
      >
      > > You will never capture a \R following a \s, because the
      > > \s will capture it first.
      >
      > So how do you explain that the two CRNL between 'xxx' and 'yyy' in...
      >
      > www
      > xxx
      >
      > yyy
      > zzz
      >
      > are both matched with '\R(\s)*\R' or '\R(\s)+\R' in NT 6.2 and NT 7.0 as well? And why, in NT 6.2, both CRNL are matched
      > with '\R\s*\R' or ''\R\s+\R'?
      >
      > So, IMHO, your statement is not fully convincing (this pertains to Alec #22593 too). See the PCRE documentation on "PCRE
      > Pattern / Newline sequences":
      >
      > "Outside a character class, by default, the escape sequence \R matches any Unicode newline sequence...In non-UTF-8 mode
      > \R is equivalent to the following: (?>\r\n|\n|\x0b|\f|\r|\x85)"
      >
      > Since CRNL, in Windows, consists of CR + NL, the sequence of two CRNL actually represents four characters. So this
      > explains the abovementioned matching. You can compare it with 'xxxx' being matched with 'x{1,2}xxx{1,2}'.
      >
      > If I'm not mistaken, the crux in Joy's problem was the DIFFERENCE between the behavior of NT 6.2 and NT 7.0 (see my
      > humble contribution in #22591). I think this difference needs some more explanation...
      >
      > Regards,
      > Flo
      >
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • Show all 15 messages in this topic