bug#8679: 24.0.50; wrong isearch highlighting for mismatch

bug#8679: 24.0.50; wrong isearch highlighting for mismatch

[Drew Adams]

In this case the mismatch highlighting is inaccurate:
 
emacs -Q
 
C-x b *scratch*
 
C-s ZZZZ
 
The entire search string is highlighted as a mismatch, which is correct.
 
M-e M-a e
 
So the edited search string is eZZZZ.
 
C-s
 
The entire search string, `eZZZZ' is highlighted, even though there are
matches for the `e'.
 
Not sure there is an easy fix for this one.  And it's not very
important.  But worth logging for future reference, at least.
 

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

bug#8679: 24.0.50; wrong isearch highlighting for mismatch

[Juri Linkov]

> Not sure there is an easy fix for this one.  And it's not very
> important.  But worth logging for future reference, at least.

Currently it has exactly the same behavior as you asked in
http://thread.gmane.org/gmane.emacs.devel/74539/focus=74614

bug#8679: 24.0.50; wrong isearch highlighting for mismatch

[Drew Adams]

> > Not sure there is an easy fix for this one.  And it's not very
> > important.  But worth logging for future reference, at least.
> 
> Currently it has exactly the same behavior as you asked in
> http://thread.gmane.org/gmane.emacs.devel/74539/focus=74614

Not as I _asked_, but as I _stated_ was probably "as good as it gets".  To which
I added, "but I'm open, if someone has a better idea".  I said "I don't know how
to fix that."

Actually, I forgot about that bug thread.  ;-)

This time I'm saying something similar, but the use case is different.  What I
said before is still true, but this report is about the behavior after `M-e', so
the consideration about a buffer change doesn't really apply.

IOW, both observations are relevant, I think.  For this use case (same buffer
where `M-e' was used), it might be good if after editing the matching part were
not highlighted as a mismatch.  Again, dunno whether that would be an easy fix -
I doubt it, but maybe you have an idea.

I have no good idea about this.  Do you?

bug#8679: 24.0.50; wrong isearch highlighting for mismatch

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> In this case the mismatch highlighting is inaccurate:
>
> emacs -Q
>
> C-x b *scratch*
>
> C-s ZZZZ
>
> The entire search string is highlighted as a mismatch, which is correct.
>
> M-e M-a e
>
> So the edited search string is eZZZZ.
>
> C-s
>
> The entire search string, `eZZZZ' is highlighted, even though there are
> matches for the `e'.

Seems to work for me.  Closing.

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

bug#8679: 24.0.50; wrong isearch highlighting for mismatch

[Drew Adams]

> > In this case the mismatch highlighting is inaccurate:
> >
> > emacs -Q
> > C-x b *scratch*
> > C-s ZZZZ
> >
> > The entire search string is highlighted as a mismatch, which is
> > correct.
> >
> > M-e M-a e
> >
> > So the edited search string is eZZZZ.
> >
> > C-s
> >
> > The entire search string, `eZZZZ' is highlighted, even though
> > there are matches for the `e'.
> 
> Seems to work for me.  Closing.

Seems to work for you apparently means little, I'm afraid.

Still a bug on Windows, at least.  The only difference in the
recipe now is that you need not use M-a.  The point is that
after inserting `e' at the front of the search string, `C-s'
still highlights the whole search string, `eZZZZ', instead of
highlighting only the mismatch portion, `ZZZZ'.

Should be reopened and fixed.

bug#8679: 24.0.50; wrong isearch highlighting for mismatch

[Eli Zaretskii]

> Date: Tue, 11 Feb 2014 07:23:26 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 8679@debbugs.gnu.org
> 
> > > In this case the mismatch highlighting is inaccurate:
> > >
> > > emacs -Q
> > > C-x b *scratch*
> > > C-s ZZZZ
> > >
> > > The entire search string is highlighted as a mismatch, which is
> > > correct.
> > >
> > > M-e M-a e
> > >
> > > So the edited search string is eZZZZ.
> > >
> > > C-s
> > >
> > > The entire search string, `eZZZZ' is highlighted, even though
> > > there are matches for the `e'.
> > 
> > Seems to work for me.  Closing.
> 
> Seems to work for you apparently means little, I'm afraid.
> 
> Still a bug on Windows, at least.  The only difference in the
> recipe now is that you need not use M-a.  The point is that
> after inserting `e' at the front of the search string, `C-s'
> still highlights the whole search string, `eZZZZ', instead of
> highlighting only the mismatch portion, `ZZZZ'.

Why is that a bug?  What do you get with this simplified recipe?

  emacs -Q
  C-s eZZZZ

When you type 'e', all the 'e's in the buffer are highlighted, but the
'e' in the echo area is highlighted in pink.  As soon as you type the
first 'Z', the highlight in the buffer goes away, and the whole "eZ"
in the echo area is colored in pink.  And that is what I would expect.

What you seem to expect happens when the search wraps around, but no
such wrap-around happens in your recipe.

bug#8679: 24.0.50; wrong isearch highlighting for mismatch

[Drew Adams]

> Why is that a bug?  What do you get with this simplified recipe?
> 
>   emacs -Q
>   C-s eZZZZ
> 
> When you type 'e', all the 'e's in the buffer are highlighted, but
> the 'e' in the echo area is highlighted in pink.

It depends where you start the search.  If you start with point
at eob then what you say is true.

If you start the search at bob then the `e' is not pink when you
just type `e'.  When you then type `ZZZZ', so your search string is
now `eZZZZ', the buffer highlighting disappears (there are no
matches).

The mismatched portion of your search string, which is the `ZZZZ'
portion, is highlighted pink, to show that it is a mismatch.
This is the correct (intended) behavior.

> As soon as you type the first 'Z', the highlight in the buffer goes
> away, and the whole "eZ" in the echo area is colored in pink.

See above.

> And that is what I would expect.

It might be all we can reasonably expect; I don't know.  Probably
Juri can answer that.  And yes, in that case this is probably
also the answer to the bug fix request: it might not be easy to
fix.

But the intended behavior of the pink highlighting is to highlight
the mismatch portion of the search string.  What this means is that
there is a bug - the intention is not to highlight also the matched
portion.  It may not be a bug that we can fix, but it is a bug.

> What you seem to expect happens when the search wraps around, but no
> such wrap-around happens in your recipe.

bug#8679: 24.0.50; wrong isearch highlighting for mismatch

[Juri Linkov]

> It might be all we can reasonably expect; I don't know.  Probably
> Juri can answer that.  And yes, in that case this is probably
> also the answer to the bug fix request: it might not be easy to
> fix.

No one proposed a better idea since this was discussed last time
in bug#14729.