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

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 07, 2015 at 03:38:31PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 7 Nov 2015 12:59:31 +0000
> > Cc: Artur Malabarba <bruce.connor.am@gmail.com>, Eli Zaretskii 
> > <eliz@gnu.org>,
> >   17453@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Proposed solutions:
> > 1. Call follow-post-command-hook from isearch-update before calling
> >   isearch-lazy-highlight-new-loop (as described above).
> > 2. Call the proposed function `redisplay-would-scroll-window' instead of
> >   the `sit-for'.
> > 3. Make isearch-lazy-highlight-new-loop always set the idle timer, and
> >   test for the need for a new loop instead in the function it triggers.
> >   Remove the `sit-for'.

> > I now think solution 2. is not sensible or realistic.  Redisplay is just
> > too complicated to second-guess.

> > Solution 1. has the disadvantage that follow-post-command-hook would be
> > called twice for every command in Isearch.  It is not fast.

> > Solution 3. similarly might have the problem that if
> > lazy-highlight-initial-delay is set to zero, redisplay might not have
> > done its work when isearch-lazy-highlight-update runs.  (I haven't tried
> > it out, yet).

> > Personally, I am in favour of solution 3, but I'm willing to be persuaded
> > into solution 1.  But I'd like us to come to a decision quickly.

> How about using 1), but also adding some indication that could prevent
> the post-command-hook from being called twice?

Hmm.  Such artifices are not pretty.  Such a flag would have to be set in
isearch.el just after isearch-update-post-hook (which calls
follow-post-command-hook) has been invoked.  Something would have to
clear it, perhaps something at the end of the lazy highlight loop.  Also,
this would couple Isearch and Follow Mode undesirably: Isearch really
shouldn't have to know anything about the FM window setup.

Or, maybe just letting follow-post-command-hook run twice wouldn't be too
bad.  The second time, all the windows would already be synchronised and
point would be in the right window.  I've had a look at the code, and it
seems in this situation it actually does call the function to rearrange
the windows.  Maybe that is a bug which might be fixed.

Do you have any views on solution 3?

-- 
Alan Mackenzie (Nuremberg, Germany).