GNU bug report logs - #8861
24.0.50; Isearch: Repeating the last search

Previous Next

Full log

Message #14 received at 8861 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Dani Moncayo'" <dmoncayo <at> gmail.com>
Cc: 8861 <at> debbugs.gnu.org
Subject: RE: bug#8861: 24.0.50; Isearch: Repeating the last search
Date: Tue, 14 Jun 2011 08:20:07 -0700

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

I already acknowledged such expectations from users.  I've had the same
expectations myself.

Dunno what else to say.  The fact is that that is not how incremental search
works - so far.  Such state - and more than a single state: a history - is not
saved.

When you are in the middle of an incremental search, some state is saved about
the last successful position etc.  But once you have exited search there is no
way to restore state, other than retrieving the last (or other previous)
complete search string to start a new search.

We could perhaps save also the last successful prefix of the last search string,
as a means to at least make the highlighting reflect that state.  

But in any case as soon as you reuse the search string (which is complete) it is
treated as a whole (e.g. hitting `DEL' deletes it all at once).  And you might
be reusing a past search string that was completely successful in some different
context (e.g. a different buffer or narrowing).  Should we record also the
current buffer and its restriction as part of the search history?  This quickly
becomes fairly complex, with design/user intention tradeoffs left and right, I
think. 

Anyway, I cannot really speak to such implementation matters; I'm no expert on
them.  I'm just giving some background explanation.  Perhaps Juri L. has an idea
about this he would like to share.  But we have discussed the issue before.

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

There's really nothing to disagree about here.  I'm just explaining what
happens.  You might like Isearch to remember your entire incremental search
history (interaction), but it does not do so at present, and it never has.

The first question is thus whether what bothers you is just the highlighting.

Are you as bothered about the fact that you cannot resume incrementally where
you left off anyway, i.e., the fact that `DEL' removes not the final char but
the whole search string, and there is thus no saved successful hit to return to
by hitting `DEL', as you are bothered about the highlighting (which reflects
that fact/behavior consistently)?

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

Patch welcome, I'm sure.  And as I say, perhaps Juri has another idea or a
better explanation of the situation.

FWIW, one alternative I can imagine, to trying to save enough historical
incremental behavior to provide the behavior you expect, would be to have
Isearch do something like the following when you hit C-s C-s and there is a
mismatch: automatically reproduce the behavior of your manually editing the
search string to remove successive rightmost characters and trying to find a
match, then proceeding with the longest successful prefix string.

IOW, it would then reproduce what you might do manually in this case, which
would be the following:

1. M-e, to edit the search string
2. DEL, to delete the rightmost char
3. C-s, to look for a match for the search string minus that char
4. If success, done.  Else repeat.

That is essentially what I do in the Icicles completion highlighting that this
Isearch highlighting was inspired from: try to complete; remove a char; repeat
until success; then highlight the part that didn't match.  Actually, this is
optimized using binary search (split the mismatch in half etc.), instead of
proceeding just a char at a time, and the same could be done for Isearch.

That would, in effect, put the previous search string in sync with the current
context (e.g. buffer).

I can see that as one possible approach/"solution".

But in that case, Isearch would be automatically discarding all that did not
match, so that suffix - and that mismatch information - would in effect be lost
to you.

And that info about mismatch could be helpful in some contexts.  Imagine that
you search for `foobar' successfully in buffer A, then want to look for it in
buffer `B', where there is `foofizz' but no `foobar'.  Maybe in that case you
would like to see that `foobar' does not match, and not just see that Isearch
transforms your C-s C-s string from `foobar' to `foo' for a successful `foo'
search?  Sure, you can type `bar' again, or you can yank `foobar' and then
search for it, but that's a bit roundabout.

If we took this approach, perhaps we should bind a key to retrieving the
discarded mismatch suffix?  Or provide a way to easily retrieve it a char at a
time, to in effect reproduce your typing it incrementally (so you need not know
or remember what the mismatch text was).

Or perhaps a better approach at that point (after determining the correct
mismatch position for the current context) would be to use the whole search
string, but (a) highlight the correct mismatch portion, and thus (b) let you, as
now, use `M-e C-k' to remove it if you want, and (c) make that the current
Isearch state: reset the failure position.

IOW, have Isearch automatically run through all the steps that would be needed
to get to the state of an incremental search that starts with the successful
prefix and proceeds incrementally to the complete (mismatched) search string,
reestablishing the correct mismatch position for the current context.  This is
essentially what you are asking for, I think.

Dunno how difficult that would be to implement.  I'm guessing it's doable, but
Juri or someone else might have more to say about it.


The point here is really the question of what it means (what the behavior should
be) to return to a previous search that failed.  Or for that matter to return to
a previous search that succeeded but now fails in a different context (same
problem).  (And that's why saving a complete previous incremental history is not
really a solution to this problem.)

Again, I am not saying that the current behavior is better than the one you are
expecting.  I am saying that what you are expecting is not implemented, and it
represents a change in the traditional behavior (wrt DEL etc.).  It might be
doable, but it would at least represent an enhancement request.

Aside from realizing such an enhancement, the highlighting could I think easily
be turned off completely in this situation.  That would not fix the overall
problem/inconsistency, but it would prevent it from being brought to your
attention so prominently.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.