GNU bug report logs - #14729
24.3.50; Isearch oddity

Previous Next

Full log

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 14729 <at> debbugs.gnu.org
Subject: Re: bug#14729: 24.3.50; Isearch oddity
Date: Sun, 30 Jun 2013 00:34:55 +0200

On Sat, Jun 29, 2013 at 11:53 PM, Juri Linkov <juri <at> jurta.org> wrote:
>> 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.
>
> `isearch-fail-pos' assumes that in a failed state of search
> a shorter previous successful search string should be taken
> as a basis for highlighting.  In this case, the last successful match
> was "buf", so an appended suffix is highlighted as failed.

Then the mistake is not re-setting that "last successful match" after
each "C-s", because here, the last successful match was "buf" only
after doing "M-< C-s buf" and also after the subsequent "C-s", but
once you type the third "C-s", the whole search string ("buf") is
unmatched (because the search now begins at [1]), and that fact (fully
unmatched search string) cannot change by appending more characters to
the search string.

IOW: After the third "C-s", the search goes from [1] to the end of the
buffer, and therefore any search string starting with a character
different from "f", "e", "r", "." or whitespace will be fully
unmatched, and should be highlighted as such in the echo area.

-----------------------
[1] Position between "buf" and "fer" in the last instance of the
string "buffer".

--
Dani Moncayo

Previous Next

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