RE: `match-data' set improperly

[Matt Swift]

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. 

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] 
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 = 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,

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.