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: Sat, 7 Nov 2015 12:59:31 +0000 Message-ID: <20151107125931.GA1770@acm.fritz.box> References: <20151102123512.GB11804@acm.fritz.box> <20151102154445.GD11804@acm.fritz.box> <87h9l46l7o.fsf@mail.linkov.net> <20151103123116.GD2258@acm.fritz.box> <83a8qvw0aq.fsf@gnu.org> <20151103221131.GG2258@acm.fritz.box> <87mvuur4kn.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 1446901161 21411 80.91.229.3 (7 Nov 2015 12:59:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Nov 2015 12:59:21 +0000 (UTC) Cc: 17453@debbugs.gnu.org, Artur Malabarba To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 07 13:59:10 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 1Zv35J-0006a8-F8 for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Nov 2015 13:59:09 +0100 Original-Received: from localhost ([::1]:43537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv35I-0003ki-SF for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Nov 2015 07:59:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv35F-0003kb-Em for bug-gnu-emacs@gnu.org; Sat, 07 Nov 2015 07:59:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zv35C-0002VQ-9b for bug-gnu-emacs@gnu.org; Sat, 07 Nov 2015 07:59:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv35C-0002VH-6N for bug-gnu-emacs@gnu.org; Sat, 07 Nov 2015 07:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zv35C-0000jv-32 for bug-gnu-emacs@gnu.org; Sat, 07 Nov 2015 07:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Nov 2015 12:59:02 +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.14469010822739 (code B ref 17453); Sat, 07 Nov 2015 12:59:02 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 7 Nov 2015 12:58:02 +0000 Original-Received: from localhost ([127.0.0.1]:56517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zv34D-0000hz-FS for submit@debbugs.gnu.org; Sat, 07 Nov 2015 07:58:01 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:34476) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zv33t-0000hX-5M for 17453@debbugs.gnu.org; Sat, 07 Nov 2015 07:58:00 -0500 Original-Received: (qmail 6721 invoked by uid 3782); 7 Nov 2015 12:57:39 -0000 Original-Received: from acm.muc.de (p579E81AA.dip0.t-ipconnect.de [87.158.129.170]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 07 Nov 2015 13:57:37 +0100 Original-Received: (qmail 2836 invoked by uid 1000); 7 Nov 2015 12:59:31 -0000 Content-Disposition: inline In-Reply-To: <87mvuur4kn.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:108518 Archived-At: 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).