GNU bug report logs - #6388
Should not match data be set on misses?

Previous Next

Package: emacs;

Reported by: Lennart Borgman <lennart.borgman <at> gmail.com>

Date: Thu, 10 Jun 2010 00:50:03 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6388 <at> debbugs.gnu.org
Subject: bug#6388: Should not match data be set on misses?
Date: Thu, 10 Jun 2010 15:35:17 +0200
On Thu, Jun 10, 2010 at 3:04 PM, Stefan Monnier
<monnier <at> 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.




This bug report was last modified 14 years and 350 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.