Re: Bug in looking-at?

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

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?