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

[Dani Moncayo <dmoncayo@gmail.com>]

Hi Drew,

> 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.)

This doesn't make much sense to me.  I expect that, whenever Isearch
is active, the search string will always be highlighted to reflect the
matched and unmatched parts at every moment, regardless of how that
string has been introduced (char by char, by copy&paste, by "C-s C-s",
...)

> 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.

I understand you, but I really disagree.  As I've said before, I'd
expect a consistent behavior with independence of the way the search
string has been built.

I don't see the need to have that double treatment.  IMHO, it is both
more consistent and useful to have a single behavior.  In the example
showed in the OP, if the search string (and the cursor position) was
updated as I suggested, I would have had a more complete/precise
information, since part of my search string did actually have matches
after the point, and that is what I wanted to know.


In short: I find my proposed behavior both (a) Simpler (more
consistent) and (b) More informative (useful) that the current one.


(Just my opinion)

-- 
Dani Moncayo