GNU bug report logs - #14729
24.3.50; Isearch oddity

Previous Next

Full log

View this message in rfc822 format

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 14729 <at> debbugs.gnu.org
Subject: bug#14729: 24.3.50; Isearch oddity
Date: Sat, 29 Jun 2013 19:22:37 +0200

On Fri, Jun 28, 2013 at 1:44 AM, Juri Linkov <juri <at> jurta.org> wrote:
>> Recipe from "emacs -Q":
>>   M-< b u f C-s C-s f e r
>
> I guess this key sequence should be rather:
>
>     M-< C-s b u f C-s C-s f e r
>
> Is this what you meant?

Yes, of course.  Silly mistake on my part.

>> After that, the echo area indicates that, in the current Isearch, I'm
>> looking for "buffer", and I've found the "buf" part, but not the
>> remaining "fer".
>>
>> That makes no sense, because that cannot happen in the current buffer,
>> where every instance of "buf" is followed by a "fer".
>
> This is an interesting state of the search.  The search is failed,
> so it assumes that adding more characters to the failed search should
> leave the search in the failed state.  Isn't this logically correct?

Of course it is correct.  If there is not match for FOO, obviously
there will be no match for FOOBAR.

> What do you expect it to do in this case?

I expect that the fontification of the echo area reflects what is
happening: that the whole search string ("buffer") is unmatched (not
only the last "fer"), since the current search begins just after the
last instance of "buf" in the buffer [1], and there is no match
(neither full nor partial) of the current search string between that
location and the end of the buffer.


------------
[1] Think of "C-s" within an Isearch session as "repeat the current
search, but starting at the current point location".

--
Dani Moncayo

Previous Next

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