From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Framework extending window functions for Follow Mode (etc.). Date: Mon, 9 Nov 2015 15:41:24 +0000 Message-ID: <20151109154124.GC2284@acm.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1447083610 11512 80.91.229.3 (9 Nov 2015 15:40:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2015 15:40:10 +0000 (UTC) Cc: 17453@debbugs.gnu.org, emacs-devel To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 09 16:40:01 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZvoXu-0004yX-Rm for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 16:39:51 +0100 Original-Received: from localhost ([::1]:53494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvoXu-0007S4-6Y for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 10:39:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvoXf-0007Ru-2I for emacs-devel@gnu.org; Mon, 09 Nov 2015 10:39:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvoXb-0008Iv-Ks for emacs-devel@gnu.org; Mon, 09 Nov 2015 10:39:34 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:48988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvoXb-0008Ik-Ar for emacs-devel@gnu.org; Mon, 09 Nov 2015 10:39:31 -0500 Original-Received: (qmail 59134 invoked by uid 3782); 9 Nov 2015 15:39:29 -0000 Original-Received: from acm.muc.de (p579E973C.dip0.t-ipconnect.de [87.158.151.60]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 09 Nov 2015 16:39:28 +0100 Original-Received: (qmail 5701 invoked by uid 1000); 9 Nov 2015 15:41:24 -0000 Content-Disposition: inline In-Reply-To: <8737wgou4z.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-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193713 Archived-At: Hello, Juri. On Mon, Nov 09, 2015 at 02:50:04AM +0200, Juri Linkov wrote: > >> This problem is already solved by enabling lazy-highlighting of the whole > >> follow-mode buffer, but I postponed installing that patch to not create merge > >> conflicts with your work in the same functions. > > My solution is to lazily highlight just the part visible in windows (but > > in all pertinent windows). Isn't highlighting all of it going to be a > > bit slow on a large buffer? > It shouldn't be slow with a sufficiently low value of lazy-highlight-max-at-a-time. OK, I see it: it would be slow if it had to go to completion, but any key/mouse/other event will terminate it. So the only place it might be a problem is somewhere where CPU cycles are at a premium. > > Part 3 of the bug is most assuredly NOT an intrinsic limitation of > > isearch-allow-scroll. It's caused by the variables w-L1 and w-L-1, the > > bounds for the permissible scrolling range in > > isearch-string-out-of-window, being set to the top and botom of the > > _single_ window. When these variables are set to the top of bottom of > > the entire FM group of windows, the bug is solved. This requires my new > > framework, or something like it. > 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)) ^ > >> > 4: With point near the bottom of a Follow Mode window, start an Isearch, > >> > and repeatedly do M-s C-e, until the highlighted match continues on to > >> > the next window. Continue doing M-s C-e until the string in the > >> > minibuffer expands by a line. At this point the top of the RH window > >> > gets spuriously scrolled into the middle of the window, leaving the FM > >> > windows unsynchronised. > >> I see the same behavior even without Isearch. > > The buggy behaviour I've described is explicitly and essentially an > > Isearch scenario. What do you mean by "the same behavior" and what > > sequence of commands generates it? > > The solution to problem 4 involves making sure point is at the right > > place at the right time when invoking isearch-message. I have made > > changes to fix it. > I meant such things as 'M-: (message "x\ny\nz") RET' causes jumping too. It causes some scrolling of windows to keep them properly aligned when the echo area expands to three lines. This is expected and proper. However, when the echo area goes back to one line, the windows don't scroll back again, leaving them unaligned. I raised a bug for this this morning. It seems it is a known problem which is tricky to solve. > >> Honestly, I see here nothing that requires a new multi-window framework. > > I want these bugs to be solved. What, then, are the alternatives to > > this framework (or something like it)? Isearch needs information about > > the Follow Mode windows, or it can't work properly. [ .... ] > > So, where do we go from here? I would like these bugs fixed for 25.1. > 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. -- Alan Mackenzie (Nuremberg, Germany).