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

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

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


From: Alan Mackenzie
Subject: bug#17453: Isearch doesn't work properly with Follow Mode.
Date: Sat, 7 Nov 2015 12:59:31 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Juri, Artur, Eli.

On Wed, Nov 04, 2015 at 02:28:08AM +0200, Juri Linkov wrote:
> >> >> This is complicated.  Ideally, the Follow Mode windows should be
> >> >> synchronised in FM's post-command-hook, not isearch's.  It is not
> >> >> isearch's job to realign windows.  follow-post-command-hook both 
> >> >> realigns
> >> >> windows and choses an appropriate window to put point in.  We should let
> >> >> it.

> >> > Once again, if some code in Isearch calls the same function that is
> >> > used in follow-post-command-hook, the above is not an issue.
> >> > Moreover, saving some calls to the hook will make Emacs more
> >> > responsive.

> >> I agree with Eli and Juri on this. If there's a solution as simple as
> >> calling a follow-mode function in isearch-post-update-hook, then this
> >> sounds like a no-downside solution.

> > I'm wondering if we're still talking about the same problem.  ;-)  A
> > simpler solution is _not_ to call a FM function from that Isearch hook.
> > Unless we're talking at cross purposes, there is simply no need.  As
> > long as the Isearch command is allowed to go to completion without
> > forcibly redisplaying, FM will re-synchronise the windows (if needed)
> > and select an appropriate window for point, all on its own (in
> > follow-post-command-hook).

> It still might help to synchronise the windows from isearch-update-post-hook
> if we'll call it before calling isearch-lazy-highlight-new-loop with sit-for.
> I see no problem in changing the order of calls to isearch-update-post-hook 
> and
> isearch-lazy-highlight-new-loop in isearch-update.  Sure, 
> follow-post-command-hook
> will be called twice but at least this simple solution for follow-mode
> doesn't require re-designing the whole lazy-highlighting machinery.

The discussion of this bug seems to have stalled.  I'd very much like to
decide all the issues now, and to fix (this part of) this bug.

Bug summary: With follow mode active, and lazy highliting active, forward
Isearch scrolls the left hand window when it should instead move to to
the right hand window.

Immediate cause: the form "(sit-for 0)" in
isearch-lazy-highlight-new-loop scrolls the window before Follow Mode has
had a chance to resynchronise everything.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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