From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: bug#17453: Isearch doesn't work properly with Follow Mode. Date: Tue, 3 Nov 2015 12:31:16 +0000 Message-ID: <20151103123116.GD2258@acm.fritz.box> References: <87h9l6627a.fsf@mail.linkov.net> <20151031235651.GE1853@acm.fritz.box> <87bnbddzpk.fsf@mail.linkov.net> <20151102092853.GA11804@acm.fritz.box> <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1446553797 27066 80.91.229.3 (3 Nov 2015 12:29:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 12:29:57 +0000 (UTC) Cc: 17453@debbugs.gnu.org, Artur Malabarba , emacs-devel To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 03 13:29:46 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ztaie-0001ro-NG for ged-emacs-devel@m.gmane.org; Tue, 03 Nov 2015 13:29:44 +0100 Original-Received: from localhost ([::1]:47719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztaie-000329-4F for ged-emacs-devel@m.gmane.org; Tue, 03 Nov 2015 07:29:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtaiU-0002wB-2X for emacs-devel@gnu.org; Tue, 03 Nov 2015 07:29:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtaiQ-0002oI-OP for emacs-devel@gnu.org; Tue, 03 Nov 2015 07:29:33 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:18307) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtaiQ-0002oC-5R for emacs-devel@gnu.org; Tue, 03 Nov 2015 07:29:30 -0500 Original-Received: (qmail 24349 invoked by uid 3782); 3 Nov 2015 12:29:28 -0000 Original-Received: from acm.muc.de (p5B14700A.dip0.t-ipconnect.de [91.20.112.10]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 03 Nov 2015 13:29:27 +0100 Original-Received: (qmail 3447 invoked by uid 1000); 3 Nov 2015 12:31:16 -0000 Content-Disposition: inline In-Reply-To: <87h9l46l7o.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193139 Archived-At: 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).