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: Isearch doesn't work properly with Follow Mode. Date: Sun, 11 May 2014 20:40:17 +0000 Message-ID: <20140511204017.GB2759@acm.acm> 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; charset=us-ascii X-Trace: ger.gmane.org 1399841130 31033 80.91.229.3 (11 May 2014 20:45:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 May 2014 20:45:30 +0000 (UTC) Cc: 17453@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 11 22:45:23 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 1Wjacd-0005ti-0I for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 22:45:23 +0200 Original-Received: from localhost ([::1]:34311 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjacc-000843-N6 for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 16:45:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjacS-00082A-NA for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 16:45:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjacK-00084n-CB for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 16:45:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjacK-00084H-9X for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 16:45:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WjacJ-00072o-Ud for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 16:45:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 May 2014 20:45:03 +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.139984106826991 (code B ref 17453); Sun, 11 May 2014 20:45:03 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 11 May 2014 20:44:28 +0000 Original-Received: from localhost ([127.0.0.1]:59715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjabj-00071F-E9 for submit@debbugs.gnu.org; Sun, 11 May 2014 16:44:27 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:54757 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjabg-000710-Sw for 17453@debbugs.gnu.org; Sun, 11 May 2014 16:44:25 -0400 Original-Received: (qmail 4972 invoked by uid 3782); 11 May 2014 20:44:23 -0000 Original-Received: from acm.muc.de (pD951AB04.dip0.t-ipconnect.de [217.81.171.4]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 May 2014 22:44:22 +0200 Original-Received: (qmail 3696 invoked by uid 1000); 11 May 2014 20:40:17 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: 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:88933 Archived-At: Hello, Stefan. On Sun, May 11, 2014 at 03:05:17PM -0400, Stefan Monnier wrote: > >> 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. OK, but it really needs a window list as a parameter, and that needs to be stored in a variable somewhere. > > 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 don't really see opportunities for this whose costs don't outweigh them. We can make a variable called `window-start-function', but then everybody has to start using (funcall window-start-function w) which is a little more obfuscated and confusing than (window-start w) just to save a (very) few calls of (window-start (car foo-windows)) . The last form is typically going to be much faster when Follow Mode is active (see below). [ Snipped bit about pre-redisplay-function. Thanks. ] > > 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. Because each time the Follow Mode window list would have to be recalculated, and this is a moderately expensive calculation, involving filtering and sorting the windows in a frame (`follow-all-followers'). This is no big deal once per command, but if done much more often will start to drag. [ .... ] > 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. There is one place where I think it is unavoidable, and that is adding lazy highlight overlays. These are currently given a `window' property to restrict their effect to the current window. In my patch, a particular match gets _two_ (or even several) overlays when it spans two or more Follow Mode windows. This can surely not be abstracted away in any sensible way. > 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 -- Alan Mackenzie (Nuremberg, Germany).