emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: re-search-forward ... nil t) results in error instead of returningni


From: Drew Adams
Subject: RE: re-search-forward ... nil t) results in error instead of returningnil
Date: Sat, 20 Nov 2004 12:45:49 -0800

       Currently, the doc suggests (to me, anyway) that the "no-fail" arg
       causes the function to return nil in case of _failure_ (and it speaks
       specifically of _error_)

    It speaks specifically of `error' in the sense or returning nil
    instead of throwing an error in case of _failure_.  Failure in this
    context means search failure:

         "Optional third argument, if t, means if fail just return nil (no
error).

Well, I disagree that the meaning you find is clear from the text. Nothing
mentions that failure here is "search failure". If this is indeed the
correct behavior, then I feel the doc should clearly speak of "failure to
find a match", and (more importantly) specify explicitly that other errors
during searching, besides non-match, are not caught.

In fact, in terms of a non-matching regexp, we should probably not speak of
"failure" or "error" at all - the regexp simply _does not match_ anything in
the search space, regardless of how searching might be implemented.

So, even just "search failure" or "match failure" is somewhat unclear,
because one might think that it means any error that occurs while searching
or trying to match. The doc should, IMO, somehow distinguish between a
non-matching regexp (a theoretical, static test) and a dynamic inability for
the program to find a match, which can be due to things like a stack
overflow. Insofar as the code that signals a `search-failed' error does not
take into account all errors that occur while searching, this needs to be
made clear. (It would be better if it took them all into account, IMO.)

I'd suggest language something like this:

            If there is no match for the regexp....
            NOTE: a non-`nil' value of NOERROR does not prevent errors
            from being raised during the search, with the exception of
            the `search-failed' error that indicates no match. For example,
            a very complex regexp can lead to a stack overflow error.


    In as far as possible performance degradation vs Emacs 20 is
    concerned, let us wait till Stefan Monnier reads this, since
    MAINTAINERS lists him as maintainer for `src/regex.c'.  I personally
    am not familiar with the details.

OK. Thanks for looking at this, Luc. Also, I'm unfamiliar with how this
stuff works, but if the behavior is not consistent (sometimes fails with
stack overflow, sometimes finds a match), then I would not think that this
is a case only of performance degradation.

Thanks,

 - Drew





reply via email to

[Prev in Thread] Current Thread [Next in Thread]