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, 10 Nov 2015 02:51:41 +0200 Organization: LINKOV.NET Message-ID: <87611a8x96.fsf@mail.linkov.net> References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.fsf@mail.linkov.net> <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447118964 13403 80.91.229.3 (10 Nov 2015 01:29:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Nov 2015 01:29:24 +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 Nov 10 02:29:12 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 1ZvxkG-0005Lt-Cl for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Nov 2015 02:29:12 +0100 Original-Received: from localhost ([::1]:56838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvxkF-0003nd-J1 for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Nov 2015 20:29:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvxkB-0003nS-GP for bug-gnu-emacs@gnu.org; Mon, 09 Nov 2015 20:29:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zvxk6-0003du-9h for bug-gnu-emacs@gnu.org; Mon, 09 Nov 2015 20:29:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvxk6-0003dd-68 for bug-gnu-emacs@gnu.org; Mon, 09 Nov 2015 20:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zvxk5-0002N7-Pj for bug-gnu-emacs@gnu.org; Mon, 09 Nov 2015 20:29: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, 10 Nov 2015 01:29: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.14471189009066 (code B ref 17453); Tue, 10 Nov 2015 01:29:01 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 10 Nov 2015 01:28:20 +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 1ZvxjP-0002MA-GO for submit@debbugs.gnu.org; Mon, 09 Nov 2015 20:28:20 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:36577 helo=homiemail-a101.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZvxjM-0002M1-SW for 17453@debbugs.gnu.org; Mon, 09 Nov 2015 20:28:17 -0500 Original-Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id 94FBC117E06C; Mon, 9 Nov 2015 17:28:13 -0800 (PST) Original-Received: from localhost.linkov.net (m212-53-104-68.cust.tele2.ee [212.53.104.68]) (Authenticated sender: jurta@jurta.org) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPA id 8A65A117E065; Mon, 9 Nov 2015 17:28:12 -0800 (PST) In-Reply-To: <20151109154124.GC2284@acm.fritz.box> (Alan Mackenzie's message of "Mon, 9 Nov 2015 15:41:24 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.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:108610 Archived-At: >> I tried to not use isearch-string-out-of-window/isearch-back-into-window >> at all, but I can't get a useful behavior in such situation of scrolling >> out of the window with the current search hit. Could you show how you see >> it should work in this case in follow-mode? > > To start with, set > > (global-set-key [next] 'follow-scroll-up) > (global-set-key [prior] 'follow-scroll-down) > (setq isearch-allow-scroll t) > > . Then start an Isearch not too close to the start of a buffer with > Follow Mode enabled with at least two windows. Type something to get a > search match highlighted. Now and should scroll that > match between Follow Mode windows, the boundaries of that scrolling being > the top of the LH window and the bottom of the RH window. > > To make this work properly, the four variables in > isearch-string-out-of-window, w-start, w-end, w-L1, w-L-1, are set to the > positions in the entire group of windows, by setting the proposed > &optional argument GROUP to t in the calls to certain window functions, > e.g. > > (let ((w-start (window-start nil t)) > ^ Could you provide the shortest patch to test the behavior that you describe? For now I tried the following, is this what you want to generalise with a new framework? diff --git a/lisp/isearch.el b/lisp/isearch.el index b762884..3b61505 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -2237,10 +2237,19 @@ (defun isearch-string-out-of-window (isearch-point) together with as much of the search string as will fit; the symbol `above' if we need to scroll the text downwards; the symbol `below', if upwards." - (let ((w-start (window-start)) - (w-end (window-end nil t)) - (w-L1 (save-excursion (move-to-window-line 1) (point))) - (w-L-1 (save-excursion (move-to-window-line -1) (point))) + (let ((w-start (window-start (and (fboundp 'follow-all-followers) + (car (follow-all-followers))))) + (w-end (window-end (and (fboundp 'follow-all-followers) + (car (last (follow-all-followers)))) + t)) + (w-L1 (save-excursion + (when (fboundp 'follow-all-followers) + (select-window (car (follow-all-followers)))) + (move-to-window-line 1) (point))) + (w-L-1 (save-excursion + (when (fboundp 'follow-all-followers) + (select-window (car (last (follow-all-followers))))) + (move-to-window-line -1) (point))) start end) ; start and end of search string in buffer (if isearch-forward (setq end isearch-point start (or isearch-other-end isearch-point)) >> The problem is that you are trying to design a new framework, >> but not demonstrated yet how it would be useful generally in cases >> other than a specific combination of isearch/follow-mode. > > Any elisp software which manipulates windows will be able to work better > by considering entire FM groups. I did some grepping: here are some > examples which the new framework could improve: > > `kill-ring-save' should blink the cursor on the matching other-end, if > that is visible. With FM active, and other end being in a different > window, currently it wrongly outputs a message instead. > > `window-screen-lines' could be enhanced (optionally) to return the number > of screen lines in the entire group. > > `blink-matching-open' could be enhanced to handle FM windows properly. > > `ns-scroll-bar-move' (probably) should `set-window-start' for the entire > window group. This (might) avoid scrolling such that the RH follow > window is displaying empty space. > > > One point about this new framework is that it is "harmless" in the sense > that anything which worked (or failed to work) prior to it will continue > unchanged unless specifically amended. It's disadvantage is that it adds > a little to the bulk of things people need to know or to look up in > manuals. > > I think Follow Mode should become easier to use, both for users and for > hackers, especially given that wide screens (>200 characters) are now the > norm rather than the exception. At the moment Follow Mode is > ridiculously difficult to start (manually splitting windows, doing M-x > follow-mode) and even more difficult to hack for - just what interfaces > are currently available for making a package work with FM? Answer: none > at all. This new framework is intended to go some way to closing the > gap. > > The alternative to a framework is a bugfix which is specific to Isearch. > Even this would require some sort of interface definition and > abstraction. At a minimum, for "part 3" of the bug, Isearch would need > somehow to obtain the bounds of the group of windows. > > The last alternative is a quick and dirty fix where Isearch would just > call Follow Mode functions. I don't think anybody really wants this. > > Would it help if I actually made the source available? If so, where? I > don't really think it would be appropriate to dump a patch of this size > on emacs-devel, and the time to commit the changes to master has clearly > not yet arrived. You are trying to do everything at once. To successfully achieve your goals it would be much more clear for us to see the progress step by step, i.e. if at first you demonstrated how to fix the co-operation between Isearch and Follow Mode by a quick and dirty fix like in the patch above then we could see how well your fixes work, and also what places need generalisation, and how your new framework would be useful here and for other packages that might benefit from it. By such inductive method we could quickly arrive to a conclusion without much friction.