bug#24914: 24.5; isearch-regexp: wrong error message

[Drew Adams <drew.adams@oracle.com>]

> >> > 3. C-M-s \(.\|^J\)\{,40000\}
> >> > That shows the error message: [incomplete input],
> >> > which is wrong, IMO.
> >>
> >> The reason it doesn't work is because the number of repitions
> >> is limited to 32767 (#x7fff).
> >
> > Yet another case for adding bignums to Emacs Lisp?
> > I imagine someone will answer that there needs to be
> > a limit.
> >
> > In that case, can we not use something larger?
> > Could we use the value of `most-positive-fixnum'?
> 
> It's not a limit in Lisp, but in regex.c.

We can't use something larger there?

> >> As to the error message itself, there isn't really a way
> >> to distinguish between incomplete and invalid input,
> >
> > We do that in some places in the code.
> 
> What places are those?

In the Lisp code, at least, there are a few places where
we provide an error that is specific to an invalid regexp.
Search for handling of standard error `invalid-regexp',
for instance.

But if this is handled only in C code then you might want
to look there instead.

> > Some code parses the regexp, and that code must know (or be able to
> > know) both that the regexp is not incomplete
> 
> What does it mean for a regexp to be incomplete or not?  As far as I can
> tell, the only distinction is that the user means to type more; but the
> code doesn't know what will happen in the future...

Presumably that term is used only for cases where we can
be sure that in order for the regexp to be valid there
would need to be further input.  `foo' is not incomplete,
whether or not the user "means to type more".  `[^' is
incomplete, because it can be made valid only by typing
more.

> > and that the numeral
> > given for the number of repetitions is too large.
> 
> I suppose we could change regex.c to give a different error message for
> a repetition number that is too high, and then isearch.el could check
> for that specially.

That would be great.