* bug#6388: Should not match data be set on misses?
@ 2010-06-10 0:42 Lennart Borgman
2010-06-10 2:03 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Lennart Borgman @ 2010-06-10 0:42 UTC (permalink / raw
To: 6388
(let ((ret (re-search-forward "some weird thing" (point-at-eol) t)))
(message "ret=%s, mb0=%s, 1" ret (match-beginning 0) (match-beginning 1)))
gives me messages like
ret=nil, mb0=517, 1
I expected
ret=nil, mb0=nil, nil
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#6388: Should not match data be set on misses?
2010-06-10 0:42 bug#6388: Should not match data be set on misses? Lennart Borgman
@ 2010-06-10 2:03 ` Eli Zaretskii
2010-06-10 13:04 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2010-06-10 2:03 UTC (permalink / raw
To: Lennart Borgman; +Cc: 6388-done
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 10 Jun 2010 02:42:59 +0200
> Cc:
>
> (let ((ret (re-search-forward "some weird thing" (point-at-eol) t)))
> (message "ret=%s, mb0=%s, 1" ret (match-beginning 0) (match-beginning 1)))
>
> gives me messages like
>
> ret=nil, mb0=517, 1
>
> I expected
>
> ret=nil, mb0=nil, nil
I'm closing this bug report because the ELisp manual explicitly
documents the current behavior:
Every successful search sets the match data. Therefore, you should
query the match data immediately after searching, before calling any
other function that might perform another search. Alternatively, you
may save and restore the match data (*note Saving Match Data::) around
the call to functions that could perform another search.
A search which fails may or may not alter the match data. In the
past, a failing search did not do this, but we may change it in the
future. So don't try to rely on the value of the match data after a
failing search.
Patches welcome to "change this in the future" (unless Stefan or
Yidong object to such a change).
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#6388: Should not match data be set on misses?
2010-06-10 2:03 ` Eli Zaretskii
@ 2010-06-10 13:04 ` Stefan Monnier
2010-06-10 13:35 ` Lennart Borgman
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2010-06-10 13:04 UTC (permalink / raw
To: 6388
> I'm closing this bug report because the ELisp manual explicitly
> documents the current behavior:
> Every successful search sets the match data. Therefore, you should
> query the match data immediately after searching, before calling any
> other function that might perform another search. Alternatively, you
> may save and restore the match data (*note Saving Match Data::) around
> the call to functions that could perform another search.
> A search which fails may or may not alter the match data. In the
> past, a failing search did not do this, but we may change it in the
> future. So don't try to rely on the value of the match data after a
> failing search.
> Patches welcome to "change this in the future" (unless Stefan or
> Yidong object to such a change).
Yes, there was a long discussion about this a few years ago. The main
obstacle to such a change are:
- it breaks some code.
- it is not tremendously useful.
- it is difficult to detect code that relies on the current behavior
(so it's difficult to output a warning to help in the migration).
The current behavior is not tremendously useful either, of course, but
it has the advantage of being what we've used for many years.
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#6388: Should not match data be set on misses?
2010-06-10 13:04 ` Stefan Monnier
@ 2010-06-10 13:35 ` Lennart Borgman
2010-06-10 18:57 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Lennart Borgman @ 2010-06-10 13:35 UTC (permalink / raw
To: Stefan Monnier; +Cc: 6388
On Thu, Jun 10, 2010 at 3:04 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I'm closing this bug report because the ELisp manual explicitly
>> documents the current behavior:
>
>> Every successful search sets the match data. Therefore, you should
>> query the match data immediately after searching, before calling any
>> other function that might perform another search. Alternatively, you
>> may save and restore the match data (*note Saving Match Data::) around
>> the call to functions that could perform another search.
>
>> A search which fails may or may not alter the match data. In the
>> past, a failing search did not do this, but we may change it in the
>> future. So don't try to rely on the value of the match data after a
>> failing search.
>
>> Patches welcome to "change this in the future" (unless Stefan or
>> Yidong object to such a change).
>
> Yes, there was a long discussion about this a few years ago.
Sorry, forgot.
> The main
> obstacle to such a change are:
> - it breaks some code.
Aka it makes some bugs (bad assumptions) surface. That is not always bad.
> - it is not tremendously useful.
But it is probably what a user/programmer normally expects.
> - it is difficult to detect code that relies on the current behavior
> (so it's difficult to output a warning to help in the migration).
> The current behavior is not tremendously useful either, of course, but
> it has the advantage of being what we've used for many years.
Yes, that is true. However the current behavior probably wastes a lot
of time for those unaware of it.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#6388: Should not match data be set on misses?
2010-06-10 13:35 ` Lennart Borgman
@ 2010-06-10 18:57 ` Stefan Monnier
0 siblings, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2010-06-10 18:57 UTC (permalink / raw
To: Lennart Borgman; +Cc: 6388
>> The main obstacle to such a change are:
>> - it breaks some code.
> Aka it makes some bugs (bad assumptions) surface. That is not always bad.
I really meant bugs, as in: the code consciously takes advantage of
current behavior. Those assumptions are only bad if we define them
that way.
> Yes, that is true. However the current behavior probably wastes a lot
> of time for those unaware of it.
Just like with programming with monitors where you're taught "always do
the wait within a `while' loop", regexp-patching should always take
place within a `if' or equivalent,
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-06-10 18:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-10 0:42 bug#6388: Should not match data be set on misses? Lennart Borgman
2010-06-10 2:03 ` Eli Zaretskii
2010-06-10 13:04 ` Stefan Monnier
2010-06-10 13:35 ` Lennart Borgman
2010-06-10 18:57 ` Stefan Monnier
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.