From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Matt Swift" Newsgroups: gmane.emacs.bugs Subject: RE: `match-data' set improperly Date: Wed, 12 Feb 2003 14:25:11 -0500 Sender: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <001001c2d2cc$7925d8c0$6200a8c0@swift.xxx> References: <5xsmutsrbv.fsf@kfs2.cua.dk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1045078593 28158 80.91.224.249 (12 Feb 2003 19:36:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 12 Feb 2003 19:36:33 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18j2WR-0006YW-00 for ; Wed, 12 Feb 2003 20:26:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18j2Xt-0006LM-03 for gnu-bug-gnu-emacs@m.gmane.org; Wed, 12 Feb 2003 14:27:49 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18j2Xf-0006KG-00 for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2003 14:27:35 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18j2Wi-0005wu-00 for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2003 14:26:37 -0500 Original-Received: from pool-68-160-54-133.bos.east.verizon.net ([68.160.54.133] helo=beth.swift.xxx) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18j2VT-0005kD-00 for bug-gnu-emacs@gnu.org; Wed, 12 Feb 2003 14:25:20 -0500 Original-Received: from vav (vav.swift.xxx [192.168.0.98])h1CJP3cv026071; Wed, 12 Feb 2003 14:25:12 -0500 Original-To: "'Kim F. Storm'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5xsmutsrbv.fsf@kfs2.cua.dk> X-Mailscanner: clean (beth.swift.xxx) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:4437 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:4437 The documentation (TeXinfo and docstrings) is pretty clear that (match-string N) when submatch N>0 does not match anything is nil, and = it is also clear that (match-string 0) is like the case for N>0 but referring = to the entire match instead of a submatch. There is no suggestion that match-data is ever undefined, once one match has been done, and the = error message you get is obscure. Certainly the problem could be simply in documentation. But the valid = value of (match-string 0) after a failure *ought* to be nil, just as it is = for, say, (match-string 4) when there is no submatch 4 or submatch 4 matched nothing. If I had to check what `string-match' and friends returned = every time before accessing the match-data, it would be a pain in the neck and = I might hallucinate that I was programming in C not Emacs-Lisp. i.e., ideally,=20 (string-match "a" "b") =3D> nil (match-data 'integers) =3D> (nil nil) (string-match "ab\\(cd\\)?\\(ef\\)?" "abef") =3D> 0 (match-data 'integers) =3D> (0 4 nil nil 2 4) (string-match "a" "b") =3D> nil (match-data 'integers) =3D> (nil nil) I do not see much use for refraining to change the match data when a = match fails (if that is what is happening, and I'm not sure it is), and = programs that want to do that can implement it easily with `save-match-data', = e.g., depending on whether one wants to be as careful as save-match-data to restore match data if there is an error when doing the `string-match',=20 (defun string-match-or-I-never-existed (r s &optional start) (let ((md (match-data)) (result (string-match r s start))) (or result (set-match-data md)) ;; NOTE above relies on undocumented but observed fact that = `set-match-data' ;; always returns nil. =20 -----Original Message----- From: Kim F. Storm [mailto:no-spam@cua.dk]=20 Sent: Wednesday, February 12, 2003 5:53 AM To: Matthew Swift Cc: bug-gnu-emacs@gnu.org Subject: Re: `match-data' set improperly Matthew Swift writes: > Evaluating the following `let' form gives varying results, but the = results > should be consistent. =20 =20 > My *guess* is that when `string-match' fails, it either fails to set > `match-data' or sets it incorrectly in one of two (or more) ways. My guess is that you are not supposed to use match-data when string-match fails, so its value is indeed undefined in that case. What _valid_ values would you expect it to contain after the match = failed?