From: Alan Mackenzie <acm@muc.de>
To: Juri Linkov <juri@linkov.net>
Cc: 17453@debbugs.gnu.org,
Artur Malabarba <bruce.connor.am@gmail.com>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode.
Date: Tue, 3 Nov 2015 12:31:16 +0000 [thread overview]
Message-ID: <20151103123116.GD2258@acm.fritz.box> (raw)
In-Reply-To: <87h9l46l7o.fsf@mail.linkov.net>
Hello, Juri.
On Tue, Nov 03, 2015 at 01:22:03AM +0200, Juri Linkov wrote:
> > So how about us just moving all these checks to where they really
> > belong, in isearch-lazy-highlight-update? I've a feeling that if we do
> > this, then your function follow--search-function becomes unneeded.
> >
> > Juri?
> Right, without (sit-for 0) it's possible to switch focus to adjacent windows
> with just adding 2 lines to follow.el, i.e. I get the desired behavior with:
> diff --git a/lisp/follow.el b/lisp/follow.el
> index 938c59e..0433854 100644
> --- a/lisp/follow.el
> +++ b/lisp/follow.el
> @@ -420,6 +420,7 @@ (define-minor-mode follow-mode
> (if follow-mode
> (progn
> (add-hook 'compilation-filter-hook 'follow-align-compilation-windows t t)
> + (add-hook 'isearch-update-post-hook 'follow-align-compilation-windows t t)
> (add-hook 'post-command-hook 'follow-post-command-hook t)
> (add-hook 'window-size-change-functions 'follow-window-size-change t))
> ;; Remove globally-installed hook functions only if there is no
> @@ -432,6 +433,7 @@ (define-minor-mode follow-mode
> (unless following
> (remove-hook 'post-command-hook 'follow-post-command-hook)
> (remove-hook 'window-size-change-functions 'follow-window-size-change)))
> + (remove-hook 'isearch-update-post-hook 'follow-align-compilation-windows t)
> (remove-hook 'compilation-filter-hook 'follow-align-compilation-windows t)))
> (defun follow-find-file-hook ()
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.
> diff --git a/lisp/isearch.el b/lisp/isearch.el
> index b762884..8edf8b0 100644
> --- a/lisp/isearch.el
> +++ b/lisp/isearch.el
> @@ -3018,7 +3018,7 @@ (defun isearch-lazy-highlight-new-loop (&optional beg end)
> search string to change or the window to scroll). It is also used
> by other Emacs features."
> (when (and (null executing-kbd-macro)
> - (sit-for 0) ;make sure (window-start) is credible
> + ; (sit-for 0) ;make sure (window-start) is credible
> (or (not (equal isearch-string
> isearch-lazy-highlight-last-string))
> (not (eq (selected-window)
> So what remains to do is to fix this bug, but I don't understand the logic
> you proposed: how checks could be moved to isearch-lazy-highlight-update
> if isearch-lazy-highlight-update is scheduled by a timer conditionally
> depending on these checks?
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[*], and thus we can use
`window-start' and `window-end' without forcing an artificial redisplay
with "(sit-for 0)".
[*] and an appropriate FM window will have been selected by FM's
post-command-hook
The disadvantage is that stale lazy highlights are erased after
isearch-lazy-highlight-initial-delay, not immediately, as at present.
I'm not sure if this is really a disadvantage or not. In my scrappy
patch last night, I attempted to ameliorate this "problem" by repeating
(most of) the tests in the command-loop bit.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2015-11-03 12:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140509224458.GA4205@acm.acm>
[not found] ` <jwva9aqbcl9.fsf-monnier+emacsbugs@gnu.org>
2015-10-29 23:23 ` bug#17453: Isearch doesn't work properly with Follow Mode Alan Mackenzie
2015-10-31 22:35 ` John Wiegley
2015-10-31 23:25 ` Alan Mackenzie
2015-10-31 23:41 ` John Wiegley
2015-11-01 11:59 ` Alan Mackenzie
2015-11-01 0:17 ` Drew Adams
2015-10-31 23:13 ` Artur Malabarba
2015-10-31 23:32 ` Alan Mackenzie
2015-11-01 12:20 ` Artur Malabarba
2015-11-01 12:23 ` Artur Malabarba
2015-11-01 13:52 ` Alan Mackenzie
2015-11-01 16:50 ` Eli Zaretskii
2015-11-01 18:27 ` Alan Mackenzie
2015-11-01 19:46 ` Artur Malabarba
2015-11-01 20:15 ` Alan Mackenzie
2015-11-01 21:37 ` Artur Malabarba
2015-11-01 20:42 ` Artur Malabarba
2015-11-01 20:54 ` Eli Zaretskii
2015-11-01 22:19 ` Alan Mackenzie
2015-10-31 23:35 ` Juri Linkov
2015-10-31 23:56 ` Alan Mackenzie
2015-11-02 0:14 ` Juri Linkov
2015-11-02 3:35 ` Eli Zaretskii
2015-11-02 9:28 ` Alan Mackenzie
2015-11-02 11:53 ` Artur Malabarba
2015-11-02 12:14 ` Artur Malabarba
2015-11-02 12:39 ` Alan Mackenzie
2015-11-02 12:35 ` Alan Mackenzie
2015-11-02 13:10 ` Artur Malabarba
2015-11-02 14:18 ` Artur Malabarba
2015-11-02 15:44 ` Alan Mackenzie
2015-11-02 23:22 ` Juri Linkov
2015-11-03 12:31 ` Alan Mackenzie [this message]
2015-11-02 23:28 ` Juri Linkov
2015-11-02 23:33 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151103123116.GD2258@acm.fritz.box \
--to=acm@muc.de \
--cc=17453@debbugs.gnu.org \
--cc=bruce.connor.am@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).