Tim Chase | 18 Aug 23:14 2012

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


Gmane