Re: Discrepancy in definition/use of match-data?

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> >>>>> "David" == David Kastrup <dak@gnu.org> writes:
> 
>     David> Now the obvious solution to that would be to make
>     David> unsuccessful matches void the match-data, too.  I myself
>     David> have no recollection of any discussions about this, but
>     David> Stephen Turnbull was pretty vocal about having proposed
>     David> something like this,
> 
> To be precise, I tried it in a workspace and was immediately slapped
> down by a regression test failure.

That in itself does not constitute a decision.  It suggests that such
a change should probably not be made lightly, and not shortly before a
release.  But it does not preclude a long-term strategy of change if
one can agree on the desirability: one would start by actively
declaring this usage deprecated (if it ever was supposed to be allowed
in the first place).  At what time one actually clamps down the code
is unrelated to the question of whether it is desirable to do so.

How strong were the results from the regression test?  What kind and
amount of code appears to be affected?

>     David> What I'll do right now is just changing the condition
>     David> that it will not flag an error for
>     David> greater-than-encountered match-data indices, except for
>     David> the case of completely void match-data where I'll still
>     David> flag an error.
> 
> I would suggest improving the error message if at all possible, and
> documenting this prominently, as it is likely to happen very rarely,
> and then only in asynchronous calls.

With the current code.  But I was also proposing to void the
match-data in the main loop: that would produce errors more often, and
only in situations where the match-data was completely unpredictable
to start with (and possibly undefined, too).  I have no clue about
the involved complexity: if this leads to a danger of, say,
recursive-edit or debug not working like before, one should postpone
till after release.

Anyway, I do not know enough about the error handling in C to propose
better error handling or messages.  I do agree that the currently
generated message is dissatisfactorily obtuse.  In particular, since
the context flagged in the traceback is the caller, and not the
particular function itself, so it is guesswork to figure out just
_what_ function triggered the "out of range" error.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum