From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#17453: Isearch doesn't work properly with Follow Mode. Date: Tue, 3 Nov 2015 12:31:16 +0000 Message-ID: <20151103123116.GD2258__45145.8819596612$1446553828$gmane$org@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 1446553828 27592 80.91.229.3 (3 Nov 2015 12:30:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 12:30:28 +0000 (UTC) Cc: 17453@debbugs.gnu.org, Artur Malabarba , emacs-devel To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 03 13:30:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Ztaj8-0002G8-Q9 for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Nov 2015 13:30:15 +0100 Original-Received: from localhost ([::1]:47727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztaj6-0003ka-Tf for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Nov 2015 07:30:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztaj0-0003fY-Oj for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2015 07:30:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ztaiz-00031v-8L for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2015 07:30:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztaiz-00031o-6A for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2015 07:30:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ztaiy-0003ej-Mq for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2015 07:30:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Nov 2015 12:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17453 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17453-submit@debbugs.gnu.org id=B17453.144655377413976 (code B ref 17453); Tue, 03 Nov 2015 12:30:04 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 3 Nov 2015 12:29:34 +0000 Original-Received: from localhost ([127.0.0.1]:50525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtaiT-0003dM-Dj for submit@debbugs.gnu.org; Tue, 03 Nov 2015 07:29:33 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:18308) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZtaiQ-0003dC-Kl for 17453@debbugs.gnu.org; Tue, 03 Nov 2015 07:29:31 -0500 Original-Received: (qmail 24359 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108345 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).