On Saturday, August 18, 2012 4:14:40 PM UTC-5, Tim Chase wrote:
> On 08/17/12 15:59, Chris Jones wrote:
> 
> > On Fri, Aug 17, 2012 at 02:01:53PM EDT, Tim Chase wrote:
> 
> >> On 08/17/12 12:51, Chris Jones wrote:
> 
> > 
> 
> >>> On Fri, Aug 17, 2012 at 11:09:21AM EDT, Tim Chase wrote:
> 
> >>>>   /r[^\n]
> 
> >>>>   /r\_[^\n]
> 
> >>>>
> 
> >>>> to no avail.  
> 
> >>>
> 
> >>>  /r[^\r] 
> 
> >>
> 
> >> Well, bust my buttons.  So "\n" is a newline on the search side, and
> 
> >> "\r" is a newline on the replacement side, but it's also a newline
> 
> >> on the search side if it's in a negated character class, but not in
> 
> >> a non-negated character class of a search?
> 
> >>
> 
> >> Confusing.
> 
> > 
> 
> > Vim fun..?
> 
> > 
> 
> > Maybe it's just a matter of putting 2 & 2 together.. even (as Ben noted)
> 
> > when they don't add up..?
> 
> > 
> 
> > All the more interesting, since in keeping with  my usual non-technical
> 
> > approach.. it was a post of yours on these aspects some two months ago
> 
> > that made me think of this course of action.. ;-)
> 
> 
> 
> Sorry I can't claim I remember the post :-)
> 
> 
> 
> So playing around with this, I've tried multiple cases and must say
> 
> I'm somewhat confused by what happens:
> 
> 
> 
>  1)  /e$
> 
>  2)  /e[\n]
> 
>  3)  /e[\r]
> 
>  4)  /e\_[\n]
> 
>  5)  /e\_[\r]
> 
>  6)  /e[^\n]
> 
>  7)  /e[^\r]
> 
>  8)  /e\_[^\n]
> 
>  9)  /e\_[^\r]
> 
> 
> 
> 1) finds "e" as the last character
> 
> 2) works like #1
> 
> 3) does not find "e" as the last character (but will find one if
> 
> there's a stray ^M after an "e" in the file)
> 
> 4) works like #1
> 
> 5) works like #1, but also finds "e" followed by ^M
> 
> 6) finds all "e" characters, including those at the EOL
> 
> 7) finds all "e" characters except those at the EOL
> 
> 8) same as #7
> 
> 9) finds all "e" characters except those followed by ^M
> 
> 
> 
> I guess it's the disparity between #2 (and #4) and #6 (and
> 
> correspondingly, #8) that I find most disconcerting: that the
> 
> negation ("^") of the set doesn't alter it from matching.
> 
> 
> 
> -tim

As I mentioned, I think it has something to do with the behavior at :help /[\n] 
which says it acts just like /_[], and it goes on to say that /_[] includes the 
newline even if the class is negated by starting with ^. Really /[^\n] is 
pointless anyway because [] doesn't match the \n character already.

It's still surprising, and still probably wrong, but that help section might 
indicate WHY it's wrong.

-- 
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Reply via email to