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: Tue, 3 Nov 2015 16:39:55 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Eli.

On Tue, Nov 03, 2015 at 05:49:17PM +0200, Eli Zaretskii wrote:
> PLEASE let's keep emacs-devel out of this??

OK.

> > Date: Tue, 3 Nov 2015 12:31:16 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: 17453@debbugs.gnu.org, Artur Malabarba <bruce.connor.am@gmail.com>,
> >     emacs-devel <emacs-devel@gnu.org>

> > 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.  (Right now, using Follow mode is a pain due to the hook:
> even a simple C-f is annoyingly slow.)

The follow-post-command-hook will run anyway.  If Isearch directly
invokes that Follow Mode function, f-p-c-h will be run a second time.
That's one of the reasons I want to avoid it.

> > What I'm proposing is to schedule the timer always, and do the checks
> > (for whether we need to start a new lazy highlight loop) in the function
> > that the timer triggers.  The advantage is that when the timer triggers,
> > redisplay will already have taken place[*]

> I don't think you can count on that: if there's a ripe timer, it will
> be processed before redisplay.  I think.

Ah.  So if somebody sets isearch-lazy-highlighting-intial-delay to
0.00001 seconds, it will trigger before redisplay has happened.  Yes.

Here's another idea.  In place of that "(sit-for 0)", I add another
condition

    (redisplay-would-scroll-window-p)

, with the following in (probably) window.el:

(defun redisplay-would-scroll-window-p (&optional pos window)
  "Would redisplay scroll WINDOW vertically on an immediate redisplay?
WINDOW defaults to the current window.  POS, the position of point which
is to be tested defaults to the value of point in WINDOW.  The buffer
displayed by WINDOW is assumed to be the current buffer.

Return t if a vertical scroll would be triggered by redisplay, otherwise nil."
  (or window (setq window (selected-window)))
  (or pos (setq pos (window-point window)))
  (with-selected-window window
    (with-current-buffer (window-buffer)
      (not
       (and (pos-visible-in-window-p pos)
            (or (<= scroll-margin 0)
                (let* ((this-scroll-margin (min scroll-margin
                                                (/ (window-body-height) 4)))
                       (top-limit
                        (save-excursion
                         (move-to-window-line this-scroll-margin)
                         (point)))
                       (bottom-limit
                        (save-excursion
                          (move-to-window-line (- this-scroll-margin))
                          (point))))
                  (and (>= pos top-limit)
                       (< pos bottom-limit)))))))))

.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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