match-beginning shouldn't signal [was: Error in process filter: (args-out-of-range 0 0)]

match-beginning shouldn't signal [was: Error in process filter: (args-out-of-range 0 0)]

[Stephen J. Turnbull]

I guess this is still of interest to auc-tex since you cc them?

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

    David> Anyway, do you copy emacs-devel as well?

No, the bug we've been discussing so far is already fixed in GNU Emacs
CVS.  I am cc'ing emacs-devel on this reply.

Summary of discussion: due to XEmacs implementation of match data,
due to a bug in our old split-string, it can signal args-out-of-range
only in a process filter.  The signal was traced to `match-beginning'.
Now David points out that this function is documented to return nil,
not signal, if its argument is a non-negative integer:

    David> I have figured out by now that the signalled error is in
    David> direct contradiction to

    `match-beginning' is a built-in function
    (match-beginning NUM)

    Documentation:
    Return position of start of text matched by last regexp search.

[BTW: We should remove "regexp" above since (match-beginning 0) at least
works for strings.]

    NUM, specifies which parenthesized expression in the last regexp.
     Value is nil if NUMth pair didn't match, or there were less than NUM pairs.
    Zero means the entire text matched by the whole regexp or whole string.

    David> Try out
    David> M-: (progn (looking-at "") (match-beginning 100)) RET

Nice catch!  Easy enough to fix in XEmacs, and probably in Emacs too
although I don't know the Emacs code.

OK.  NUM < 0 is an out-of-range error.  That should be
non-controversial.

Due to usages like

    (re-search-forward (if state regexp-of-1-group regexp-of-2-groups))

which I think is both natural and useful (don't ask me for a use yet
:-), I don't see how X?Emacs can determine the maximum number of
groups that have actually been searched.

So I would say that for NUM >= 0 match-* should _always_ return either
the appropriate match-data or nil.  If sanity-checking for
non-negative NUM seems appropriate, write a wrapper macro.

For plain string searches, I would say that's really an optimization
of regexp searching, and we should _not_ signal an error on NUM > 0 if
the last search was a string search.

XEmacs's implementation imposes an upper limit on the number of groups
whose match-data is recorded, and I suppose GNU Emacs does too.  Maybe
we should signal an out-of-range error in that case, preferably with a
message indicating that this is an implementation restriction.  I tend
to be against this, though, especially since different implementations
could have different limits.

What do you think?

    David> This bug is both in CVS Emacs and in XEmacs 21.4.13 AFAICS.

It will be in all non-ancient XEmacs versions, because they signal an
out-of-range error if the register has not been allocated.



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.