* Bug in looking-at?
@ 2005-08-13 16:35 Lennart Borgman
2005-08-13 19:57 ` Lennart Borgman
2005-08-14 17:21 ` Richard M. Stallman
0 siblings, 2 replies; 8+ messages in thread
From: Lennart Borgman @ 2005-08-13 16:35 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug in looking-at?
2005-08-13 16:35 Bug in looking-at? Lennart Borgman
@ 2005-08-13 19:57 ` Lennart Borgman
2005-08-14 21:12 ` Lennart Borgman
2005-08-14 17:21 ` Richard M. Stallman
1 sibling, 1 reply; 8+ messages in thread
From: Lennart Borgman @ 2005-08-13 19:57 UTC (permalink / raw)
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-:
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug in looking-at?
2005-08-13 19:57 ` Lennart Borgman
@ 2005-08-14 21:12 ` Lennart Borgman
2005-08-14 21:50 ` Jason Rumney
2005-08-14 21:58 ` Jason Rumney
0 siblings, 2 replies; 8+ messages in thread
From: Lennart Borgman @ 2005-08-14 21:12 UTC (permalink / raw)
Cc: Emacs Devel
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug in looking-at?
2005-08-14 21:12 ` Lennart Borgman
@ 2005-08-14 21:50 ` Jason Rumney
2005-08-14 21:58 ` Jason Rumney
1 sibling, 0 replies; 8+ messages in thread
From: Jason Rumney @ 2005-08-14 21:50 UTC (permalink / raw)
Cc: Emacs Devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug in looking-at?
2005-08-14 21:12 ` Lennart Borgman
2005-08-14 21:50 ` Jason Rumney
@ 2005-08-14 21:58 ` Jason Rumney
2005-08-14 22:39 ` Lennart Borgman
1 sibling, 1 reply; 8+ messages in thread
From: Jason Rumney @ 2005-08-14 21:58 UTC (permalink / raw)
Cc: Emacs Devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug in looking-at?
2005-08-14 21:58 ` Jason Rumney
@ 2005-08-14 22:39 ` Lennart Borgman
2005-08-15 23:42 ` Lennart Borgman
0 siblings, 1 reply; 8+ messages in thread
From: Lennart Borgman @ 2005-08-14 22:39 UTC (permalink / raw)
Cc: Emacs Devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug in looking-at?
2005-08-14 22:39 ` Lennart Borgman
@ 2005-08-15 23:42 ` Lennart Borgman
0 siblings, 0 replies; 8+ messages in thread
From: Lennart Borgman @ 2005-08-15 23:42 UTC (permalink / raw)
Cc: Emacs Devel, Jason Rumney
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug in looking-at?
2005-08-13 16:35 Bug in looking-at? Lennart Borgman
2005-08-13 19:57 ` Lennart Borgman
@ 2005-08-14 17:21 ` Richard M. Stallman
1 sibling, 0 replies; 8+ messages in thread
From: Richard M. Stallman @ 2005-08-14 17:21 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-08-15 23:42 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-13 16:35 Bug in looking-at? Lennart Borgman
2005-08-13 19:57 ` Lennart Borgman
2005-08-14 21:12 ` Lennart Borgman
2005-08-14 21:50 ` Jason Rumney
2005-08-14 21:58 ` Jason Rumney
2005-08-14 22:39 ` Lennart Borgman
2005-08-15 23:42 ` Lennart Borgman
2005-08-14 17:21 ` Richard M. Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.