From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#17453: Framework extending window functions for Follow Mode (etc.). Date: Thu, 19 Nov 2015 02:45:43 +0200 Organization: LINKOV.NET Message-ID: <87egfmkea0.fsf@mail.linkov.net> References: <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447895303 29707 80.91.229.3 (19 Nov 2015 01:08:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 01:08:23 +0000 (UTC) Cc: 17453@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 19 02:08:14 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 1ZzDhr-00034L-AM for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 02:08:11 +0100 Original-Received: from localhost ([::1]:39003 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzDhq-0004Hq-QC for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 20:08:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzDhm-0004Gh-8b for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 20:08:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzDhi-0004wa-TI for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 20:08:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzDhi-0004wM-QG for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 20:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZzDhi-000650-6p for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 20:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Nov 2015 01:08: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.144789526923334 (code B ref 17453); Thu, 19 Nov 2015 01:08:02 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 19 Nov 2015 01:07:49 +0000 Original-Received: from localhost ([127.0.0.1]:43896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzDhU-00064G-Dw for submit@debbugs.gnu.org; Wed, 18 Nov 2015 20:07:48 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:45790 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzDh9-00063I-T8 for 17453@debbugs.gnu.org; Wed, 18 Nov 2015 20:07:46 -0500 Original-Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8232745807C; Wed, 18 Nov 2015 17:07:27 -0800 (PST) Original-Received: from localhost.linkov.net (m91-131-172-22.cust.tele2.ee [91.131.172.22]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 62D6F45807B; Wed, 18 Nov 2015 17:07:26 -0800 (PST) In-Reply-To: <20151118175814.GA1690@acm.fritz.box> (Alan Mackenzie's message of "Wed, 18 Nov 2015 17:58:14 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) 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:108894 Archived-At: >> For consistency with other related names it could have the same prefix, e.g. >> "window-group-recenter". > > Or even "recenter-window-group", since "window-group" isn't strictly a > prefix in a lot of the other cases anyway. Maybe "recenter-window-group" in the sense of "recenter a window in the window group" as opposed to "window-group-recenter" in the sense of "recenter the whole window group"? >> 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. >> 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. > > 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. You could try to append a new follow+isearch specific hook to post-command-hook in follow.el, if this helps. >> Would this help to avoid new problems such as un-highlighting >> postponed until the timer fires? > > Is this actually a problem? I played with Emacs a little with that > un-highlighting strategy, and didn't find it any more disturbing than > the 0.25s gap between old highlighting going and new highlighting > arriving. We need to test the same in all modes that use lazy-highlighting too.