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: Framework extending window functions for Follow Mode (etc.). Date: Wed, 25 Nov 2015 19:33:01 +0000 Message-ID: <20151125193301.GI2007@acm.fritz.box> References: <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> <20151117225558.GC5054@acm.fritz.box> <878u5w3zf2.fsf@mail.linkov.net> <20151118175814.GA1690@acm.fritz.box> <87egfmkea0.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 1448479900 16928 80.91.229.3 (25 Nov 2015 19:31:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 19:31:40 +0000 (UTC) Cc: 17453@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 25 20:31:27 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 1a1fmo-0002LU-GM for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Nov 2015 20:31:26 +0100 Original-Received: from localhost ([::1]:47339 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1fmq-0002q9-3Z for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Nov 2015 14:31:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1fmV-0002Sg-Ko for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 14:31:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1fmQ-00028B-K2 for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 14:31:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1fmQ-000287-H4 for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 14:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a1fmQ-0008BI-3Q for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 14:31: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: Wed, 25 Nov 2015 19:31: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.144847986031440 (code B ref 17453); Wed, 25 Nov 2015 19:31:02 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 25 Nov 2015 19:31:00 +0000 Original-Received: from localhost ([127.0.0.1]:53154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1fmO-0008B2-3O for submit@debbugs.gnu.org; Wed, 25 Nov 2015 14:31:00 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:53406) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1fmL-0008At-Iw for 17453@debbugs.gnu.org; Wed, 25 Nov 2015 14:30:58 -0500 Original-Received: (qmail 33610 invoked by uid 3782); 25 Nov 2015 19:30:56 -0000 Original-Received: from acm.muc.de (p5B146B74.dip0.t-ipconnect.de [91.20.107.116]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 25 Nov 2015 20:30:55 +0100 Original-Received: (qmail 23138 invoked by uid 1000); 25 Nov 2015 19:33:01 -0000 Content-Disposition: inline In-Reply-To: <87egfmkea0.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:109257 Archived-At: Hello, Juri It's been nearly a week since your last email. In that time, I tried one of the approaches (see below) that worked just fine.... except it wouldn't work with replace.el. I got discouraged by this, and moved onto other things for a while. Now I'm back. On Thu, Nov 19, 2015 at 02:45:43AM +0200, Juri Linkov wrote: > >> Another thing that disturbs me is moving lazy-highlighting checks > >> to a new function isearch-lazy-highlight-maybe-new-loop. > > What disturbs you about this change in particular? > The same consequences you mentioned earlier: various time periods > of lazy-highlighting staying active. OK. > >> What do you think about moving only window-checking into new function > >> i.e. only checks for window-start/window-end/etc that need (sit-for 0) > >> and leaving other checks in isearch-lazy-highlight-new-loop? > > Actually, I think that "(sit-for 0)" isn't needed - I left it in to deal > > with isearch-lazy-highlight-initial-delay being set to 0, thinking that > > Follow Mode's post-command-hook might "not have had time" to run. But > > surely post-command-hook will be called before checking timers. I'll > > need to look at the source code (probably keyboard.c) to be absolutely > > sure of this. The "(sit-for 0)" is absolutely not needed: post-command-hook is indeed always invoked before Emacs checks for timer expiry; I tried this out. > > I don't think splitting the checks between > > isearch-lazy-highlight-new-loop (in the command loop) and a function > > triggered by a timer is a good idea. I tried it out, and it kind of > > jars when the lazy highlighting sometimes stays 0.25s, sometimes goes > > instantly. How about maybe ... > > How about maybe putting the test for new highlighting in Isearch's > > post-command-hook (and using the APPEND argument of `add-hook' to make > > sure Isearch's post-hook-function comes after Follow Modes's)? That > > way, all the lazy h. would be removed immediately after the command, as > > at present. This is precisely what I tried. It works very well in Isearch. However, the problem is in replace.el (the replace functionality, not `occur'): `query-replace', instead of using the Command Loop like Isearch does, implements its own command loop. This seems suboptimal: it doesn't invoke post-command-hook (or pre-command-hook) until the entire replace session is over. This means the use of `query-replace' whilst Follow Mode is enabled is not going to work properly, without some radical change in replace.el. Probably the smallest change would be to invoke new hooks `pre-replace-command-hook' and `post-replace-command-hook' from `query-replace''s command loop. A more satisfying change would be to get rid of `perform-replace' and use Emacs's command loop the way Isearch does. This would probably not be all that difficult. Do you know if there's any special reason `query-replace' implements its own command loop? What do you think? [ .... ] > We need to test the same in all modes that use lazy-highlighting too. Yes. That's a problem, right now. -- Alan Mackenzie (Nuremberg, Germany).