From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#17453: Isearch doesn't work properly with Follow Mode. Date: Sun, 11 May 2014 15:05:17 -0400 Message-ID: References: <20140509224458.GA4205@acm.acm> <20140511125842.GA11781@acm.acm> <20140511181832.GA2759@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1399835189 9673 80.91.229.3 (11 May 2014 19:06:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 May 2014 19:06:29 +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 Sun May 11 21:06:22 2014 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 1WjZ4n-0005m9-J6 for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 21:06:21 +0200 Original-Received: from localhost ([::1]:34020 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjZ4n-0006Z7-0d for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 15:06:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjZ4c-0006Y2-8q for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 15:06:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjZ4U-0005Lr-Km for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 15:06:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjZ4U-0005Ln-H4 for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 15:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WjZ4U-0004EG-6w for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 15:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 May 2014 19:06: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.139983512716204 (code B ref 17453); Sun, 11 May 2014 19:06:02 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 11 May 2014 19:05:27 +0000 Original-Received: from localhost ([127.0.0.1]:59591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjZ3u-0004DH-AL for submit@debbugs.gnu.org; Sun, 11 May 2014 15:05:26 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:45099) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjZ3r-0004D4-Me for 17453@debbugs.gnu.org; Sun, 11 May 2014 15:05:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNMCqwB/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kLodWCNIZF456B4Q4BKkZgWqDTCE X-IPAS-Result: ArUGAIDvNVNMCqwB/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kLodWCNIZF456B4Q4BKkZgWqDTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62358016" Original-Received: from 76-10-172-1.dsl.teksavvy.com (HELO pastel.home) ([76.10.172.1]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 May 2014 15:05:17 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 60C0D602A0; Sun, 11 May 2014 15:05:17 -0400 (EDT) In-Reply-To: <20140511181832.GA2759@acm.acm> (Alan Mackenzie's message of "Sun, 11 May 2014 18:18:32 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) 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: 140.186.70.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:88925 Archived-At: >> follow-mode.el doesn't, indeed, but since you're moving some follow mode >> code to isearch.el, .... > Am I? No code that currently is in follow-mode.el will cease to be in > follow-mode.el. Please replace "moving" with "adding" in my phrase, then. > No, Follow Mode will know nothing about Isearch. Isearch will know about > follow-mode's internal structures, namely its list of windows, and what > their sequencing means. In that sense, the two libraries are coupled, > which isn't, other things being equal, good, but I can't see how to > avoid it. Can you see a way of avoiding this coupling? I gave one suggestion to uncouple them in one specific spot, yes. There's no general answer for such problems, so we have to look at every part of the coupling and try to find solutions for each part. >> It shouldn't be too difficult. It's just a matter of refactoring: >> change your patch so that on isearch.el's side it only adds some hooks, >> which are then set follow-mode.el. > Do you mean "set to a function in follow-mode.el". I think you're > suggesting writing more functions in follow-mode.el. Do you mean > something like a Follow Mode equivalent of `window-start'? Right, I think introducing new functions/hooks to get the beginning/end of the visible part of the buffer, which can then be overridden by follow-mode would probably be part of the solution. > I know the motivation for the change. For what functionalities should > code be come up with that will be incorporated into these hooks? What > will the hooks do, specifically? I don't know. You know the code better than I do, so hopefully you can come up with good ideas. > I didn't know about pre-redisplay-function. It looks new. As an aside, > its documentation is unclear (what is a "set" of windows, for example, As is common in (Emacs) Lisp, sets are represented as a list. > and what sort of things are allowed/not allowed in a hook function > (deleting windows, for example)?) Noone knows, really. > Is it for "bring-region-into-sight" and friends that you envisage adding > hooks? Yes. > I'm not sure how well a hook would work for this functionality, since in > the "plain" hook function you'd want to pass it a window, whereas in the > "follow" hook function you'd want to pass it a list of windows. I don't see why you'd need to pass anything like a window or a list of windows. All it needs is a region and a point. The window (or set thereof) would be passed implicitly via selected-window, as usual. > OK. So you're thinking of somewhere like subr.el, with something like > (defun scroll-region-into-window/s (start end window/s above > opposite-important) ....) > where WINDOW/S is either a single window or a list of them, START END > bound the region, OPPOSITE-IMPORTANT is t when the region boundary > "nearest the window" is to be preferred for display when the region's too > big. Or something like that. Maybe we could add a parameter for desired > margin at the top/bottom of the window. Something like that, yes. > OK. Formulating a good description of that parameter is tricky, though. Right, designing an API is often tricky. > The whole patch addresses the main bug; forming generally useful > subroutines out of isearch-string-out-of-window and friends is the other > bug, which I'm suggesting be dealt with separately. I don't want to add code specific to follow-mode directly in Isearch. So the way to fix the bug is in 2 steps: - refactor Isearch so that it adds the hooks we need (some of this, may involve creating new functions in subr.el such as discussed above). - change follow-mode.el to set those hooks as appropriate. There's then a 3rd step which is to make other packages than Isearch use those same new functions/hooks, but that one can be postponed. Stefan