Bug in looking-at?

Bug in looking-at?

[Lennart Borgman]

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.

Re: Bug in looking-at?

[Lennart Borgman]

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

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?

Re: Bug in looking-at?

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

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

No, there is no ^M in the buffer.

Re: Bug in looking-at?

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

>>> 2. Then copy the last (looking-at ...), place point as before and
>>> run with M-S-:.
>>>   It should fail to match again.

Should it fail? If so, then what is the bug?

> Richard has replied that he does not see this problem on his system
> (GNU/Linux I suppose).

What is the problem? Everything that you said SHOULD happen does, on
both GNU/Linux and W32. So I don't think I see it either.

Re: Bug in looking-at?

[Lennart Borgman]

Jason Rumney wrote:

>Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>  
>
>>>>2. Then copy the last (looking-at ...), place point as before and
>>>>run with M-S-:.
>>>>  It should fail to match again.
>>>>        
>>>>
>
>Should it fail? If so, then what is the bug?
>
>  
>
>>Richard has replied that he does not see this problem on his system
>>(GNU/Linux I suppose).
>>    
>>
>
>What is the problem? Everything that you said SHOULD happen does, on
>both GNU/Linux and W32. So I don't think I see it either.
>  
>
Hm. Yes, I can see now I misunderstood the [:space:] character class. It 
was not exactly what I thought. I believed \r and \n belonged to this 
character class (though I understand it can not).

This explains why the pattern did not match. However it does not explain 
why it matched later in point 3. I am still so surprised by this that I 
had to test it once again to be sure.

Re: Bug in looking-at?

[Lennart Borgman]

Lennart Borgman wrote:

> Jason Rumney wrote:
>
>>> Richard has replied that he does not see this problem on his system
>>> (GNU/Linux I suppose).
>>>   
>>
>>
>> What is the problem? Everything that you said SHOULD happen does, on
>> both GNU/Linux and W32. So I don't think I see it either.
>>  
>>
> Hm. Yes, I can see now I misunderstood the [:space:] character class. 
> It was not exactly what I thought. I believed \r and \n belonged to 
> this character class (though I understand it can not).
>
> This explains why the pattern did not match. However it does not 
> explain why it matched later in point 3. I am still so surprised by 
> this that I had to test it once again to be sure.

To my surprise I can not reproduce this now. I did several tests before 
with emacs -Q and it work the way I described all the times. Richard 
can't see it, Jason don't see the problem, I could see it but not now. 
It is beginning to look like a possibly intermittent hardware memory 
problem to me. But I am not sure yet, those are hard to track down. So - 
just drop it for now at least. I will come back if I come to another 
conclusion than the one above.

Re: Bug in looking-at?

[Richard M. Stallman]

    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.

They both succeed for me.
So I guess the bug is Windows-only.