emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Font-lock spillover with C-s M-e


From: Stephen Berman
Subject: Re: Font-lock spillover with C-s M-e
Date: Fri, 06 Jul 2007 01:09:18 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

On Thu, 05 Jul 2007 22:22:41 +0200 Christian Schlauer <address@hidden> wrote:

> Observed with Emacs 22.1:
>
> - emacs -q --no-site-file
>
> - Go to the beginning of the *scratch* buffer with M-< (Now, you
>   should see the usual three-line text at the beginning of the
>   *scratch* buffer).
>
> - C-s M-e create C-s C-s
>
> At this point the font-lock in the buffer is looking strange:
> everything from point (at the beginning of the buffer) to the last
> match is coloured in the face "isearch".

It's not font-locking but an overlay set by isearch-highlight.

> This only occurs when M-e is pressed in the above recipe: without M-e,
> the font-lock spillover doesn't occur.

I think the problem arises as follows:

1. Typing `C-s' in the minibuffer after editing the search string
doesn't change point in the buffer being searched, so

2. when isearch-push-state updates the vector isearch-cmds, it records
point where the search began (above, at (point-min)), instead of where
the successful search ended (above, after "create").

3. Then, after the search fails, the last line of isearch-search puts
point in this position.

4. Subsequently, isearch-update calls isearch-highlight on the region
determined by that latter position and the position just before the
last succesful search, resulting in the observed "spillover".

It seems that the attached patch fixes this, but I do not know the
isearch code well, and the comment "This code is very hairy" in
isearch-edit-string is a bit intimidating, so caveat lector.

Steve Berman

Attachment: txtotc5rpdvI7.txt
Description: isearch-edit-string patch


reply via email to

[Prev in Thread] Current Thread [Next in Thread]