bug#17453: Isearch doesn't work properly with Follow Mode.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Nov 02, 2015 at 05:46:34PM +0200, Eli Zaretskii wrote:
> Lets' take emacs-devel out of this shall we?

OK.

> > Date: Mon, 2 Nov 2015 12:35:12 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Juri Linkov <juri@linkov.net>, 17453@debbugs.gnu.org,
> > 	Stefan Monnier <monnier@iro.umontreal.ca>,
> > 	emacs-devel <emacs-devel@gnu.org>

> > > Maybe I missed part of the issue. I thought you wanted Isearch to
> > > switch to another window if that window contains the next match
> > > (instead of scrolling the current window). For that, you only need
> > > pos-visible-in-window-p, you don't need to mess with boundaries.

> > What is causing the unwanted scrolling rather than moving to the next
> > window, is the form "(sit-for 0)" near the start of
> > isearch-lazy-highlight-new-loop.  When point is outside the window, this
> > form causes redisplay, which scrolls point back into the window -
> > without Follow Mode getting a look in.  In my patch, I replaced this
> > with "(sit*-for 0)", where Follow Mode can do its thing before the
> > redisplay happens.

> If this means that sit*-for does something other than redisplay and
> wait, like switch to another window, I'd really suggest to rethink
> that.  It is entirely counter-intuitive to have a sit-for family of
> functions do anything other than some kind of redisplay and some kind
> of waiting.

sit*-for's synchronising windows, switching to the appropriate window,
etc., is conceptually an extension of redisplay's scrolling to get point
on screen.  But I think sit*-for could well be not needed here, anyway.

> I think it is a better idea to have Isearch switch to another window
> when the next hit is there, via some specialized movement command that
> Follow mode could customize.  That'd be something expectable.

No.  The right fix is not to do "(sit-for 0)" at that point in the
processing.  As I explained at length to Artur in another post today, if
we move lazy-highlight's checking whether window-start/end have changed,
into the function triggered by the timer, redisplay will already have
happened and so we won't need that offending sit-for.

Then Follow Mode will quite naturally select the next window (via its
post-command-hook), rather than isearch forcibly scrolling the first
one.  As currently happens when lazy highlighting is disabled.

-- 
Alan Mackenzie (Nuremberg, Germany).