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: Thu, 13 Feb 2003 01:42:30 -0500 Sender: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <001301c2d32b$17f71b40$6200a8c0@swift.xxx> References: <200302130054.SAA09991@eel.dms.auburn.edu> 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 1045118669 5336 80.91.224.249 (13 Feb 2003 06:44:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 13 Feb 2003 06:44:29 +0000 (UTC) Cc: "'Kim F. Storm'" 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 18jD43-0001IW-00 for ; Thu, 13 Feb 2003 07:41:44 +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 18jD5F-0000Rb-03 for gnu-bug-gnu-emacs@m.gmane.org; Thu, 13 Feb 2003 01:42:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18jD57-0000Qp-00 for bug-gnu-emacs@gnu.org; Thu, 13 Feb 2003 01:42:49 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18jD52-0000Qc-00 for bug-gnu-emacs@gnu.org; Thu, 13 Feb 2003 01:42:48 -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 18jD51-0000Q2-00 for bug-gnu-emacs@gnu.org; Thu, 13 Feb 2003 01:42:44 -0500 Original-Received: from vav (vav.swift.xxx [192.168.0.98])h1D6gNBI007035; Thu, 13 Feb 2003 01:42:32 -0500 Original-To: "'Luc Teirlinck'" 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 In-reply-to: <200302130054.SAA09991@eel.dms.auburn.edu> Importance: Normal X-Mailscanner: clean (beth.swift.xxx) Original-cc: bug-gnu-emacs@gnu.org 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:4449 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:4449 I stand corrected. Nevertheless I see a strong case for revising both the documentation and = the behavior of the function. Searches fail frequently and are often = expected to fail, and though I acknowledge the relevant information was = available, I will presume to say that reasonably competent, conscientious, and experienced people can overlook it. This essential information should = be in the docstring and the TeXinfo documentation of `string-match' etc, not merely in the TeXinfo discussion of these functions.=20 The second sentence you quote is almost meaningless. "did not do this" = -- did not do WHAT? alter it, or not alter it? Likewise, one cannot tell = what might be changed to what in the future. As I wrote earlier today, I find good reasons to want failed searches to = set the match data in a manner consistent with failed submatches, and I see = no good reason to refrain from doing so. I doubt the efficiency advantage = to declining to set the match-data to (nil nil) is even measurable, and as = a matter of principle, well-defined data can not be less useful than = undefined data. -----Original Message----- From: Luc Teirlinck [mailto:teirllm@dms.auburn.edu]=20 Sent: Wednesday, February 12, 2003 7:55 PM To: Matthew Swift Cc: bug-gnu-emacs@gnu.org; 'Kim F. Storm' Subject: `match-data' set improperly Matthew Swift wrote: The documentation (TeXinfo and docstrings) is pretty clear that (match-string N) when submatch N>0 does not match anything is nil, and =3D it is also clear that (match-string 0) is like the case for N>0 but referring =3D to the entire match instead of a submatch. There is no suggestion that match-data is ever undefined, once one match has been done, The following in the Elisp manual (Chapter: Searching and Matching, = Simple Match Data Access) suggests exactly that to me: 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. Sincerely, Luc.