Re: error in regex handling of \n?

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


--
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