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: Tue, 01 Dec 2015 02:07:31 +0200 Organization: LINKOV.NET Message-ID: <874mg33ubg.fsf@mail.linkov.net> References: <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> <20151125193301.GI2007@acm.fritz.box> <8737vs8isw.fsf@mail.linkov.net> <20151130203723.GA24162@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448928566 10653 80.91.229.3 (1 Dec 2015 00:09:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Dec 2015 00:09:26 +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 Tue Dec 01 01:09:11 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 1a3YVK-00055u-Kk for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Dec 2015 01:09:10 +0100 Original-Received: from localhost ([::1]:43987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3YVJ-0006Gu-Ru for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Nov 2015 19:09:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3YVF-0006Ge-Qy for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 19:09:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3YVC-0003M6-C3 for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 19:09:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3YVC-0003M0-8f for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 19:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a3YVB-0002f5-Ji for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 19:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Dec 2015 00:09:01 +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.144892853410218 (code B ref 17453); Tue, 01 Dec 2015 00:09:01 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 1 Dec 2015 00:08:54 +0000 Original-Received: from localhost ([127.0.0.1]:33411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3YV4-0002ek-30 for submit@debbugs.gnu.org; Mon, 30 Nov 2015 19:08:54 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:57963 helo=homiemail-a11.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3YUj-0002eJ-W4 for 17453@debbugs.gnu.org; Mon, 30 Nov 2015 19:08:53 -0500 Original-Received: from homiemail-a11.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTP id 37CAC6E06C; Mon, 30 Nov 2015 16:08:33 -0800 (PST) Original-Received: from localhost.linkov.net (m213-102-86-182.cust.tele2.ee [213.102.86.182]) (Authenticated sender: jurta@jurta.org) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTPA id 13F916E06A; Mon, 30 Nov 2015 16:08:31 -0800 (PST) In-Reply-To: <20151130203723.GA24162@acm.fritz.box> (Alan Mackenzie's message of "Mon, 30 Nov 2015 20:37:23 +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:109482 Archived-At: >> The patch in bug#20430 awaits the possibility of helping to fix this >> problem. It adds a new hook replace-update-post-hook that is like >> its isearch counterpart hook isearch-update-post-hook is the right way >> to handle display updates like syncing follow windows, etc. > > Does this patch exist, yet? Yes, you can find the patch in http://debbugs.gnu.org/20430#8 > It bothers me a little that we might be adding hook after hook into > Emacs, each one for a single special purpose. Fortunately, a new hook is not for a single special purpose - it's a general type of hook, requested for different user needs. > Would it not perhaps be better to call `isearch-update-post-hook' also > from `perform-replace', since that would be more economical with hooks; > the meaning of the hook invocation would be "the same" in Isearch and > `perform-replace' - "hook called after having moved to the next match". Logically, it makes sense to reuse isearch hooks in query-replace since query-replace searches for matches like isearch does, but practically users might have such customizations in .emacs that would break query-replace in unpredictable ways. This is why a separate query-replace hook would be much safer. I see no problem for follow-mode to add follow-post-command-hook to both hooks. >> Together with changing the order of calling isearch-update-post-hook >> and isearch-lazy-highlight-new-loop in isearch-update, adding >> follow-post-command-hook to isearch-update-post-hook, and adding >> follow-post-command-hook to replace-update-post-hook to handle >> follow-mode in query-replace will comprise the least radical change >> just before the next release. > > This sounds like a good idea. Though, again, I think calling > isearch-update-post-hook from `query-replace' would be better than > implementing a new hook. Adding a new hook is just a one-liner, but we have to find the right place in perform-replace to call it. I think replace-update-pre-hook should be called before (read-event), and replace-update-post-hook after (read-event). I'm not yet sure which one is needed for follow-mode to sync windows? > Would it still be possible to mark `isearch-update-post-hook' as "for > internal use only", so that we could get rid of it later? isearch-update-post-hook is a first-class hook added 5 years ago, so there is no need to remove it.