bug#8861: 24.0.50; Isearch: Repeating the last search

[Drew Adams]

Juri or someone else might give a better or different explanation, but here's
mine, FWIW.

This behavior is not very clear or intuitive, but (a) there is not much that can
be done about it, and (b) it can be argued that it is not really a bug.

The highlighting could perhaps be turned off completely in this case, since in
does not (cannot) correctly indicate only the part of the search string that is
incorrect.  (But turning it off completely gives the opposite message that there
is no search failure.)

The highlighting as it appears is at least consistent with the rest of Isearch
behavior in this context.  The search string was not sought incrementally; that
is, no incremental search built it up.  So there is no notion of the increment
of it that failed.  If you hit `DEL' (Backspace) at that point, it is not just
the final `e' that is removed, but all of the search string.

IOW, you cannot return to a successful search prefix and return in the buffer to
a successful search hit position.  In this context, the entire search string
_is_ the increment: it is sought as a whole.  There is no previous successful
state to return to, and that principle extends to the success/failure match
highlighting.

I know and agree that this might not be what a user expects, especially since
this highlighting is something new, but it is consistent.  The highlighting
here, like all the rest of the searching, is not incremental at that point.  The
search string as a whole is tested and either succeeds (as a whole) or fails (as
a whole).  The highlighting reflects that.

And it can only reflect that.  Perhaps we could remove it, but I'm not sure that
would be better.  In that case the "bug" or unituitive behavior would be that
search fails but the search string is not highlighted at all to show failure.