GNU bug report logs - #17453
Isearch doesn't work properly with Follow Mode.

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Fri, 9 May 2014 22:50:02 UTC

Severity: normal

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17453 <at> debbugs.gnu.org, bruce.connor.am <at> gmail.com, juri <at> linkov.net
Subject: bug#17453: Isearch doesn't work properly with Follow Mode.
Date: Sun, 8 Nov 2015 10:32:32 +0000
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 <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
> >   17453 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> 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).




This bug report was last modified 9 years and 218 days ago.

Previous Next


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