[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange behavior in search-forward-regexp?
From: |
Barry Margolin |
Subject: |
Re: Strange behavior in search-forward-regexp? |
Date: |
Fri, 10 Feb 2006 21:04:27 -0500 |
User-agent: |
MT-NewsWatcher/3.4 (PPC Mac OS X) |
In article <m2wtg21xhd.fsf@gmail.com>,
Mathias Dahl <brakjoller@gmail.com> wrote:
> Take these "buffers":
>
> Buffer 0:
>
> ---------- this line is not part of the buffer ----------
> row0;test0
> row1;test1
> row2;test2
> ---------------------------------------------------------
>
> Buffer 1:
>
> ---------- this line is not part of the buffer ----------
>
> row0;test0
> row1;test1
> row2;test2
> ---------------------------------------------------------
>
> Evaluate these functions:
>
> (defun test1 ()
> (interactive)
> (save-excursion
> (goto-char (point-min))
> (if (search-forward-regexp "^[^;]+;.*test1" nil t)
> (message (match-string-no-properties 0)))))
>
> (defun test2 ()
> (interactive)
> (save-excursion
> (goto-char (point-min))
> (if (search-forward-regexp "^.*test1" nil t)
> (message (match-string-no-properties 0)))))
>
> In buffer 0, test1 and test2 willreturn the same result, "row1;test1",
> but in buffer 1, test1 will return "\nrow1;test1" (\n is a newline)
> and test2 "row1;test1".
>
> Can someone explain this to me? Why would, in the case of test1, the
> newline be included just because the line before is empty?
Because the regular expression . matches any character except newline,
while [^;] matches any character except ';'. So newline matches [^;].
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Re: Strange behavior in search-forward-regexp?, Peter Dyballa, 2006/02/11