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

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

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

Starting from emacs -Q:

1. Go to the beginning of the *scratch* buffer (M-<).
2. Search for "filee" (C-s filee) and type <enter> to accept the
current cursor position.
3. Repeat the last search (C-s C-s).

After step #3, the minibuffer shows the entire seach string "filee" as
unmatched, but the first 4 characters *do* have matching words after
the cursor position.  So only the last "e" should be displayed as
unmatched.

IOW, I should get the same result with (C-s C-s) as with (C-s filee)
(i.e. retyping the search string).

A picture is worth a thousand words. See attached screenshots:
* "img-wrong.png": Observed result.
* "img-right.png": Expected result.


In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-06-07 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'


-- 
Dani Moncayo

[-- Attachment #2: img-wrong.png --]
[-- Type: image/png, Size: 17708 bytes --]

[-- Attachment #3: img-right.png --]
[-- Type: image/png, Size: 17820 bytes --]

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.

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

[Dani Moncayo]

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

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

[Drew Adams]

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

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

[Juri Linkov]

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

Currently it's possible to reproduce the behavior you are asking for,
by copy&paste from the system clipboard into Emacs running in xterm
(it pastes char by char):

1. emacs -Q -nw
2. M-<
3. C-s S-Ins

When trying this, it seems it's worse than the default behavior because
treating the search string char by char is useful only when you are
typing it because highlighting the failed part helps to correct typos.
But when you want to search for the previous search string by `C-s C-s'
or by copy&paste from the clipboard/kill-ring it's more useful
to treat it as a whole.  For instance, often it's necessary to
put a string into the search ring (`C-s string RET') and search
its exact occurrence in another buffer (`C-x o C-s C-s').
It would be annoying when searching for e.g. "caterpillar"
will stop at "cat" and highlight it.

However, your idea is not completely useless.  Currently isearch mode
is interactively incremental but you propose to extend it it into
non-interactively incremental (i.e. incremental even when the search
string is not composed interactively).  Maybe a new option/mode
could do that but I think it should not be enabled by default.

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

[Dani Moncayo]

Hi Juri,

> It would be annoying when searching for e.g. "caterpillar"
> will stop at "cat" and highlight it.

Well, IMO, it would be TRT.  Once you see that result, if you consider
it useless, just dismiss it with C-g.

Also, think of a situation like having "caterpillars" in the top of
the search ring and then doing C-s C-s in a buffer which doesn't have
it, but has "caterpillar" (singular).  In that case, I would like
Isearch to move the point forward to the next occurrence of the second
one.  Yes, it isn't a full match, but is a _useful_one_ for me.

> However, your idea is not completely useless.  Currently isearch mode
> is interactively incremental but you propose to extend it it into
> non-interactively incremental (i.e. incremental even when the search
> string is not composed interactively).  Maybe a new option/mode
> could do that but I think it should not be enabled by default.

It would be useful, IMO.  Thanks.

PS: Currently, my knowledge of Emacs Lips is too basic to been able to
contribute anything useful.  Maybe in the future.  I have the
intention of keep learning... :)

-- 
Dani Moncayo

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

[Stefan Monnier]

>> It would be annoying when searching for e.g. "caterpillar"
>> will stop at "cat" and highlight it.
> Well, IMO, it would be TRT.  Once you see that result, if you consider
> it useless, just dismiss it with C-g.

The fact that the whole "filee" is highlighted is not a feature
(i.e. patches to change it might be accepted).
I'm less sure about the idea to make it jump to the first match of
"file", tho I'm not necessarily opposed to it.
Oh and BTW, I'm using local patches to make DEL remove only the final
char rather than the whole "filee", so I'm not opposed to changing this
part of the behavior either.


        Stefan

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

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

> When trying this, it seems it's worse than the default behavior because
> treating the search string char by char is useful only when you are
> typing it because highlighting the failed part helps to correct typos.
> But when you want to search for the previous search string by `C-s C-s'
> or by copy&paste from the clipboard/kill-ring it's more useful
> to treat it as a whole.  For instance, often it's necessary to
> put a string into the search ring (`C-s string RET') and search
> its exact occurrence in another buffer (`C-x o C-s C-s').
> It would be annoying when searching for e.g. "caterpillar"
> will stop at "cat" and highlight it.

Yes, it would be pretty odd...

> However, your idea is not completely useless.  Currently isearch mode
> is interactively incremental but you propose to extend it it into
> non-interactively incremental (i.e. incremental even when the search
> string is not composed interactively).  Maybe a new option/mode
> could do that but I think it should not be enabled by default.

... and in my opinion, I don't think such a would find much use, so I'm
closing this issue as "wontfix".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Juri Linkov]

>> When trying this, it seems it's worse than the default behavior because
>> treating the search string char by char is useful only when you are
>> typing it because highlighting the failed part helps to correct typos.
>> But when you want to search for the previous search string by `C-s C-s'
>> or by copy&paste from the clipboard/kill-ring it's more useful
>> to treat it as a whole.  For instance, often it's necessary to
>> put a string into the search ring (`C-s string RET') and search
>> its exact occurrence in another buffer (`C-x o C-s C-s').
>> It would be annoying when searching for e.g. "caterpillar"
>> will stop at "cat" and highlight it.
>
> Yes, it would be pretty odd...
>
>> However, your idea is not completely useless.  Currently isearch mode
>> is interactively incremental but you propose to extend it it into
>> non-interactively incremental (i.e. incremental even when the search
>> string is not composed interactively).  Maybe a new option/mode
>> could do that but I think it should not be enabled by default.
>
> ... and in my opinion, I don't think such a would find much use, so I'm
> closing this issue as "wontfix".

Please close also bug#14729 for the same reason, these two requests
are about the same fuzzy oddities with no clear solution.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

> Please close also bug#14729 for the same reason, these two requests
> are about the same fuzzy oddities with no clear solution.

I think that one could possibly lead to improvement, though.  😀  (I
mean, theoretically.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no