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: Thu, 5 Nov 2015 12:38:27 +0000 Message-ID: <20151105123827.GA2887@acm.fritz.box> References: <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> <20151104090106.GA1736@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1446727051 23413 80.91.229.3 (5 Nov 2015 12:37:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 12:37:31 +0000 (UTC) Cc: 17453@debbugs.gnu.org, Juri Linkov To: Artur Malabarba Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 05 13:37:19 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 1ZuJn3-00022t-Bb for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Nov 2015 13:37:17 +0100 Original-Received: from localhost ([::1]:60246 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuJn2-0001Bn-QV for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Nov 2015 07:37:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuJmt-0001Ac-MJ for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2015 07:37:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuJmo-0000Ed-Hq for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2015 07:37:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuJmo-0000EY-EB for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2015 07:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZuJmo-0002Oq-7p for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2015 07:37: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: Thu, 05 Nov 2015 12:37: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.14467270069202 (code B ref 17453); Thu, 05 Nov 2015 12:37:02 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 5 Nov 2015 12:36:46 +0000 Original-Received: from localhost ([127.0.0.1]:54263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZuJmX-0002OL-DW for submit@debbugs.gnu.org; Thu, 05 Nov 2015 07:36:45 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:34524) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZuJmU-0002OB-W3 for 17453@debbugs.gnu.org; Thu, 05 Nov 2015 07:36:43 -0500 Original-Received: (qmail 62300 invoked by uid 3782); 5 Nov 2015 12:36:40 -0000 Original-Received: from acm.muc.de (p5B1477AD.dip0.t-ipconnect.de [91.20.119.173]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 05 Nov 2015 13:36:40 +0100 Original-Received: (qmail 3405 invoked by uid 1000); 5 Nov 2015 12:38:27 -0000 Content-Disposition: inline In-Reply-To: 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:108476 Archived-At: Hello, Artur. On Wed, Nov 04, 2015 at 10:17:09AM +0000, Artur Malabarba wrote: > 2015-11-04 9:01 GMT+00:00 Alan Mackenzie : > >> 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 still say, wait until we really need it before we do anything so > > drastic. As Eli noted, follow-post-command-hook is SLOW, SLOW, SLOW. > > If we call it twice per command, it will be twice as slow. > > Also, why is the "(sit-for 0)" there at all? As its comment says, It > > is there for one purpose, and one purpose only: it is so that > > (window-start) is valid, and the check > > (not (= (window-start) > > isearch-lazy-highlight-window-start)) > > will work. This check means exactly "has the window scrolled?" > Have you tested redisplay-would-scroll-window-p in a fully folded > org-mode buffer with 100 headlines where each headline has 100 lines > of content? Of course not. :-) By the way, what does Isearch do with such org-mode folded buffer? Does it unfold the content, ever? > If you report that it works in this context and isn't slow then I'm ok > with going with this solution. Like I said, as long as it doesn't > cause regressions, this would be a fine refactoring to do in > isearch.el. So we might as well apply it now and give any possible > issues some time to surface (isearch is used by tons of people, so I'm > sure they'll surface if any exist). > While you're at it, if you could also refactor all those `(not (equal > ...))' tests into a single `isearch--lazy-highlight-needs-update-p' > function that would be very welcome (and if you do, do it as a > separate commit before everything else so the other stuff is easy to > revert separately). I don't agree this is a good idea. At the moment, all these tests are in the same not too big defun that sets them. This kind of keeps things together - for instance if a new test was to be introduced, only this one function would need amending. > And if it looks like I'm saying "I'm fine with this" to everything > here, that's because I am. It sounds like we're debating two fine > options and bordering on bikeshedding. So I say: merge one and see how > it goes. I'm pretty much ready to do this. But maybe you could answer my question about unfolding org-mode buffers above, first. Thanks! > Cheers -- Alan Mackenzie (Nuremberg, Germany).