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 17:46:53 -0400 Message-ID: References: <20140509224458.GA4205@acm.acm> <20140511125842.GA11781@acm.acm> <20140511181832.GA2759@acm.acm> <20140511204017.GB2759@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1399844907 11895 80.91.229.3 (11 May 2014 21:48:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 May 2014 21:48:27 +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 23:48:20 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 1WjbbY-0001WI-3L for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 23:48:20 +0200 Original-Received: from localhost ([::1]:34443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjbbX-0003Fd-PS for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 17:48:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjbbN-0003BD-Jk for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 17:48:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjbbG-0001Lb-36 for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 17:48:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjbbF-0001LX-VW for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 17:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WjbbF-0001Qs-ME for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 17:48:01 -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 21:48: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.13998448245427 (code B ref 17453); Sun, 11 May 2014 21:48:01 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 11 May 2014 21:47:04 +0000 Original-Received: from localhost ([127.0.0.1]:59785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjbaJ-0001PS-1U for submit@debbugs.gnu.org; Sun, 11 May 2014 17:47:03 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:25007) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjbaG-0001Oj-CZ for 17453@debbugs.gnu.org; Sun, 11 May 2014 17:47:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kLodWCNIZF456B4Q4BKsDg0wh X-IPAS-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kLodWCNIZF456B4Q4BKsDg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62368934" Original-Received: from 23-91-155-216.cpe.pppoe.ca (HELO pastel.home) ([23.91.155.216]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 May 2014 17:46:53 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 891CD600A4; Sun, 11 May 2014 17:46:53 -0400 (EDT) In-Reply-To: <20140511204017.GB2759@acm.acm> (Alan Mackenzie's message of "Sun, 11 May 2014 20:40:17 +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:88940 Archived-At: >> 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 don't understand. Why would it need to be both in a parameter and in a variable somewhere? And isn't it already in some follow-mode "variable" somewhere? window-start does not need a window parameter (it does accept such a parameter, optionally, but that's just to avoid some with-selected-window), so I don't think such new function would need such a parameter either. > 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) I see two options: - either some/many calls need to be changed to use the new API. - or follow-mode advises window-start. And of course, it would be (funcall window-start-function), without the `w'. > which is a little more obfuscated and confusing than > (window-start w) To make it less obfuscated, we can provide a new function `viewable-area-start' which does (funcall window-start-function). > . The last form is typically going to be much faster when Follow Mode is > active (see below). Not sure about "much". My gut feeling would be rather around "not noticeably". >> 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 I don't see why. Isn't/can't the "Follow Mode window list" be kept as a window-parameter, so you can get it quickly? > 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. Indeed, recomputing it for every window-start call would make it expensive. I assume that it can be cached such that we only recompute it when it changes (e.g. using window-configuration-change-hook). > 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. You might be right. As mentioned, I think follow-mode is important enough to warrant special treatment, so we can probably leave a few hacks in there, in case no useful/sensible abstraction can be invented. In this case of isearch-vs-followmode, I think the way to find the useful abstractions is to try and figure out "what would be useful/useable for other packages than isearch". Window-specific overlays are not used very often, the candidates seem to be: - region highlighting. - rectangular region highlighting. - compare-w.el. Stefan