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

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

> >> >> 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.
> 
> As far as I can tell, none of those places (apart from isearch.el, the
> subject of this bug) try to flag "incomplete" regexps, only invalid or
> valid.

Isn't that the point?  In the case in question the regexp is
not incomplete.  It is "invalid" because the occurrences
count is too high.  Showing a message that says it is
incomplete is wrong - that was the point of this report.

What I cited are cases where we do flag _particular kinds_
of invalid regexps, and so tailor the error msg.  That's
what could be hoped for in the current case too: ideally,
show a msg that says that the occurrences count is too high.
If that can't be detected exactly then perhaps we can get
close - e.g., invalid occurrences count or some such.

> >> > 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.
> 
> Is `\\{100,20\\}' incomplete?  Because it could be made valid
> by the user adding a 0 after the 20 to become '\\{100,200\\}'.

Of course, a user could always use `M-e' to edit the search
pattern and type 0 before the \\}.  But our isearch messages
don't take that kind of thing into account.  They assume the
cursor is at the _end_ of the search pattern, so that further
input is appended to the pattern.

An incomplete-regexp message means (so far, aside from bugs
like this one or perhaps cases where Emacs cannot do better)
that we expect you to keep typing - at the end of the search
pattern, to complete a valid regexp.

> Actually, I'm wondering what's the point of isearch showing
> "incomplete" instead of the actual regexp invalid error.
> I.e., why not instead of
> 
>     \ [incomplete]
>     \{ [incomplete]
>     \{4 [incomplete]
>     \{4000 [incomplete]
>     \{4000\ [incomplete]
>     \{4000\}
> 
> show this:
> 
>     \ [Trailing backslash]
>     \{ [Unmatched \{]
>     \{4 [Unmatched \{]
>     \{4000 [Unmatched \{]
>     \{4000\ [Trailing backslash]
>     \{4000\}

Feel free to work on that.  You might run into some cases
that are not so clear-cut.  But you might well improve
things generally in some way.

The problem with that is (I suppose) that it is not, in
general, straightforward what would be needed to make
the current pattern a valid regexp.

In particular, there might be multiple ways to make it
valid.  Trying to describe what you're expecting, as
possible appended input that would make for a valid
regexp, would be hard.

And doing it accurately, even when feasible, would lead
to complex error msgs.  It's maybe more user-friendly
to just indicate that, so far, the regexp is not valid,
but that it could become valid by appending something
(i.e., without trying to accurately characterize that
something).

Anyway, unless working on that is needed or appropriate
for fixing the reported bug, that should perhaps be
dealt with by a separate bug (enhancement request).