From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#6388: Should not match data be set on misses? Date: Wed, 09 Jun 2010 22:03:08 -0400 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1276136902 24428 80.91.229.12 (10 Jun 2010 02:28:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 10 Jun 2010 02:28:22 +0000 (UTC) Cc: 6388-done@debbugs.gnu.org To: Lennart Borgman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 10 04:28:21 2010 connect(): No such file or directory Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OMXVE-0001ev-ET for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Jun 2010 04:28:20 +0200 Original-Received: from localhost ([127.0.0.1]:55726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMXVD-0000PC-J8 for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Jun 2010 22:28:19 -0400 Original-Received: from [140.186.70.92] (port=45399 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMXV8-0000P2-3t for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 22:28:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMXV6-00015H-Ti for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 22:28:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56220) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMXV6-000158-RD for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 22:28:12 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OMX7i-0006Tn-2Z for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2010 22:04:02 -0400 Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2010 02:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 6388 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 6388@debbugs.gnu.org, eliz@gnu.org Original-Received: via spool by 6388-done@debbugs.gnu.org id=D6388.127613539524899 (code D ref 6388); Thu, 10 Jun 2010 02:04:01 +0000 Original-Received: (at 6388-done) by debbugs.gnu.org; 10 Jun 2010 02:03:15 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMX6w-0006TY-Ro for submit@debbugs.gnu.org; Wed, 09 Jun 2010 22:03:15 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMX6u-0006TT-Nm for 6388-done@debbugs.gnu.org; Wed, 09 Jun 2010 22:03:13 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1OMX6q-0004aE-VV; Wed, 09 Jun 2010 22:03:08 -0400 In-reply-to: (message from Lennart Borgman on Thu, 10 Jun 2010 02:42:59 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 09 Jun 2010 22:04:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:37641 Archived-At: > From: Lennart Borgman > 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).