Re: Bug in looking-at?

[Lennart Borgman]

Lennart Borgman wrote:

> Lennart Borgman wrote:
>
> > Second time today I think I have found a bug... What should I say... 
> > Hope this one is ok ;-)
> >
> > (defun bug-looking-at()
> >  "Instructions for showing the possible bug:
> > 1. Place the point before \(interactive\) and run this function.
> >   The first looking-at succeeds, the second fails.
> > 2. Then copy the last (looking-at ...), place point as before and run 
> > with M-S-:.
> >   It should fail to match again.
> > 3. Now recall this in M-S-: and add character s last in the regexp.
> >   This time it should match. Try removing the s again..."
> >  (interactive)
> >  (unless (looking-at "(interactive)")
> >    (error "Please put the point at \(interactive\)"))
> >  (message "Second (looking-at ...) => %s" (looking-at 
> > "(interactive)[[:space:]]+(unles")))
> >
> > I am doing this on w32, Emacs from 9 aug, emacs -Q.
>
>
> Some more information. Looking at the char syntax:
>
> (message "%s,%s,%s"
>        (string (char-syntax ?\t))
>        (string (char-syntax ?\r))
>        (string (char-syntax ?\n)))
>
> gives " ,_,>" -- this is whitespace character, symbol constituent and 
> comment ender.
>
> Could part of the problem here be that the syntax table is broken on 
> w32 since ?\r is symbol constituent? But this can not be the whole 
> story, since it behaves differently when run through -S-:

Richard has replied that he does not see this problem on his system 
(GNU/Linux I suppose). I have the following to add:

- Setting the syntax for \r to either " " or ">" does not make 
looking-at return t.
- If however [[:space:]] is replaced with [ \t\r\n] then looking-at 
returns t.

To me there seems to be a couple of strange things going on. I have no 
idea even where to start looking. Can someone else please test on at 
least w32?