Strange behavior in search-forward-regexp?

Strange behavior in search-forward-regexp?

[Mathias Dahl]

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?

Re: Strange behavior in search-forward-regexp?

[Barry Margolin]

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?

[Mathias Dahl]

Barry Margolin <barmar@alum.mit.edu> writes:

> Because the regular expression . matches any character except newline, 
> while [^;] matches any character except ';'.  So newline matches [^;].

So what happens is that the match begin at the empty line then and
then "wraps around" to the next row? How can I avoid it?

Re: Strange behavior in search-forward-regexp?

[Peter Dyballa]

Am 11.02.2006 um 02:43 schrieb Mathias Dahl:

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

Could you check the encodings used in the two buffers?

--
Greetings

   Pete

The box said "Use Windows 95 or better," so I got a Macintosh

Re: Strange behavior in search-forward-regexp?

[Mattis]

> > 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".
>
> Could you check the encodings used in the two buffers?

Actually, I was bluffing when I wrote I had two buffers. :) It was easier to
explain that way.

And, to answer your question:

Coding system for saving this buffer:
  1 -- iso-latin-1 (alias: iso-8859-1 latin-1)

Re: Strange behavior in search-forward-regexp?

[Peter Dyballa]

Am 11.02.2006 um 20:00 schrieb Mattis:

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

I've seen the same behaviour of search-forward-regexp "^[^;]+;.*text"  
a few times, wrapping around into the next line. It's obvious that  
newline is not semicolon, so it complies with the search regexp. I  
have no better advice than to use a non-discriminating regexp, i.e.  
search for a set of real characters.

It would probably make more sense to learn the new set of descriptors  
for regexp's (the Perl look alikes), and in which version of GNU  
Emacs they actually work ...

--
Greetings

   Pete

“Computers are good at following instructions, but not at reading  
your mind.”
    - D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

Re: Strange behavior in search-forward-regexp?

[Mathias Dahl]

Peter Dyballa <Peter_Dyballa@web.de> writes:

> I've seen the same behaviour of search-forward-regexp "^[^;]+;.*text"
> a few times, wrapping around into the next line. It's obvious that
> newline is not semicolon, so it complies with the search regexp. I
> have no better advice than to use a non-discriminating regexp, i.e.
> search for a set of real characters.

The solution was easy:

(defun test3 ()
  (interactive)
  (save-excursion
    (goto-char (point-min))
    (if (search-forward-regexp "^[^\n.;]+;.*test1" nil t)
        (message (match-string-no-properties 0)))))

Thanks for the hint, you just fixed a bug in tumme! :)

Re: Strange behavior in search-forward-regexp?

[Barry Margolin]

In article <m27j825iw0.fsf@gmail.com>,
 Mathias Dahl <brakjoller@gmail.com> wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
> 
> > Because the regular expression . matches any character except newline, 
> > while [^;] matches any character except ';'.  So newline matches [^;].
> 
> So what happens is that the match begin at the empty line then and
> then "wraps around" to the next row? How can I avoid it?

Use [^;<newline>] in the regular expression, where <newline> is entered 
with C-q C-j.

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

[Mathias Dahl]

Barry Margolin <barmar@alum.mit.edu> writes:

>> So what happens is that the match begin at the empty line then and
>> then "wraps around" to the next row? How can I avoid it?
>
> Use [^;<newline>] in the regular expression, where <newline> is entered 
> with C-q C-j.

Thanks!  That's what I eventually did (although I used `\n'
instead)and posted the answer here, but it seems thet gmane or the
list has had problems yesterday.

Re: Strange behavior in search-forward-regexp?

[Barry Margolin]

In article <m2hd74fwu9.fsf@gmail.com>,
 Mathias Dahl <brakjoller@gmail.com> wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
> 
> >> So what happens is that the match begin at the empty line then and
> >> then "wraps around" to the next row? How can I avoid it?
> >
> > Use [^;<newline>] in the regular expression, where <newline> is entered 
> > with C-q C-j.
> 
> Thanks!  That's what I eventually did (although I used `\n'
> instead)and posted the answer here, but it seems thet gmane or the
> list has had problems yesterday.

Yeah, I didn't remember until after I posted that you were doing this in 
code, not interactively.  When using interactive re-search, you have to 
type C-q C-j.

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