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: Sun, 8 Nov 2015 00:29:55 +0000 Message-ID: <20151108002955.GC1774@acm.fritz.box> References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> <871tc18oai.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 1446942506 6236 80.91.229.3 (8 Nov 2015 00:28:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 00:28:26 +0000 (UTC) Cc: Artur Malabarba , emacs-devel To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 01:28:17 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 1ZvDq9-0003Td-Sp for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 01:28:14 +0100 Original-Received: from localhost ([::1]:45653 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvDq9-0006VL-6K for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 19:28:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvDq5-0006V5-8i for emacs-devel@gnu.org; Sat, 07 Nov 2015 19:28:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvDq0-0000lc-7Q for emacs-devel@gnu.org; Sat, 07 Nov 2015 19:28:09 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:33667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvDpz-0000lE-Ru for emacs-devel@gnu.org; Sat, 07 Nov 2015 19:28:04 -0500 Original-Received: (qmail 68659 invoked by uid 3782); 8 Nov 2015 00:28:02 -0000 Original-Received: from acm.muc.de (p548A50E3.dip0.t-ipconnect.de [84.138.80.227]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 08 Nov 2015 01:28:00 +0100 Original-Received: (qmail 3253 invoked by uid 1000); 8 Nov 2015 00:29:55 -0000 Content-Disposition: inline In-Reply-To: <871tc18oai.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:193573 Archived-At: Hello, Juri. On Sat, Nov 07, 2015 at 11:58:29PM +0200, Juri Linkov wrote: > >> I admit I am confused. I thought we had narrowed down three possible > >> solutions to this issue (which you just listed over at the bug thread), all > >> of which are simpler than this code. > > Those solutions are to merely one part of the bug, namely C-s wrongly > > scrolling a window instead of moving onto the next one. > > The other parts of #17453 are: > > 2: lazy highlighting is confined to one Follow Mode window (I'm a bit > > confused as to the status of this, though); > 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? > > 3: With isearch-allow-scroll enabled, it is not possible to scroll point > > to the next or previous Follow Mode window; > > , in addition to which I have a fix for ... > That's because isearch-post-command-hook uses isearch-pre-scroll-point > to move it back, so it's possible to nullify isearch-pre-scroll-point > in follow-mode, but I see that it leaves the highlighted found string > at its old position because the isearch-allow-scroll feature doesn't support > finding the next search hit after scrolling, or something like this > that would make sense. IOW, this is a limitation of isearch-allow-scroll. In my personal copy of Emacs, I've had the isearch scrolling working properly with Follow Mode for ~18 months. It was me that wrote the isearch scrolling code in the first place, back in 2003. 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. > > 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. > 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 far, I've written three solutions for these bugs, as I outlined at length in an email to Martin R. today. The first of these solutions was (justifiably) rejected by Stefan because it was a quick and dirty fix, and he explicitly requested the new framework that I have now built. Eli didn't like the second attempt and explicitly suggested the way for my third attempt. You and Martin dislike this most recent third attempt. It seems to me I've spent more time discussing this bug on the bug list and emacs-devel, and reformulating the fix, than actually tracking down and fixing the bugs in the first place. At the moment I feel like I'm trying to hack down a wall of constant negativity. I don't recall anybody else saying positively they want this bug fixed, and I certainly don't feel I've had much encouragement wrt this bug, in the last few days and weeks. I see Follow Mode as being a critically important component of Emacs, the more so since very wide (240 characters and more) screens displaced the fairly narrow CRT monitors. I would like every Emacs user to be able to use FM as easily as I can. Right at the moment there is no suitable interface to FM for libraries that require to do their own window manipulation. Such an interface is what Stefan wanted, and it's what I want, too. As of yet, there's been practically no discussion of this interface I've written, beyond Eli suggesting the current version and John suggesting a name change for some hooks. So, where do we go from here? I would like these bugs fixed for 25.1. -- Alan Mackenzie (Nuremberg, Germany).