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: Mon, 30 Nov 2015 20:37:23 +0000 Message-ID: <20151130203723.GA24162@acm.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1448915790 5157 80.91.229.3 (30 Nov 2015 20:36:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Nov 2015 20:36:30 +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 Mon Nov 30 21:36: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 1a3VBD-0007mG-JZ for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Nov 2015 21:36:11 +0100 Original-Received: from localhost ([::1]:43247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3VBC-0002NA-Py for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Nov 2015 15:36:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3VB8-0002KD-2P for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 15:36:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3VB4-0002dg-SP for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 15:36:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3VB4-0002dc-PO for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 15:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a3VB4-0004KM-Jr for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2015 15:36: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: Mon, 30 Nov 2015 20:36: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.144891572616592 (code B ref 17453); Mon, 30 Nov 2015 20:36:02 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 30 Nov 2015 20:35:26 +0000 Original-Received: from localhost ([127.0.0.1]:33303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3VAS-0004JX-Vv for submit@debbugs.gnu.org; Mon, 30 Nov 2015 15:35:25 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:56123) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3VAP-0004JL-C7 for 17453@debbugs.gnu.org; Mon, 30 Nov 2015 15:35:22 -0500 Original-Received: (qmail 5731 invoked by uid 3782); 30 Nov 2015 20:35:19 -0000 Original-Received: from acm.muc.de (p548A5058.dip0.t-ipconnect.de [84.138.80.88]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 30 Nov 2015 21:35:17 +0100 Original-Received: (qmail 20934 invoked by uid 1000); 30 Nov 2015 20:37:23 -0000 Content-Disposition: inline In-Reply-To: <8737vs8isw.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:109476 Archived-At: Hello, Juri. On Fri, Nov 27, 2015 at 01:03:43AM +0200, Juri Linkov wrote: > > 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? > 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? It bothers me a little that we might be adding hook after hook into Emacs, each one for a single special purpose. 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". > 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. > Do you see a shortcoming of this course of action? Only that it is working around the problems in replace.el rather than fixing them. But to fix them properly would mean a radical redesign of `perform-replace', or superseding it altogether, which is probably best postponed until 25.2 or later. I still think `post-command-hook' is the best hook for us to use - but it isn't called from `query-replace'. 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? -- Alan Mackenzie (Nuremberg, Germany).