From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Framework extending window functions for Follow Mode (etc.). Date: Sat, 07 Nov 2015 23:58:29 +0200 Organization: LINKOV.NET Message-ID: <871tc18oai.fsf@mail.linkov.net> References: <20151105192905.GA7986@acm.fritz.box> <20151107182420.GA1774@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446935875 10006 80.91.229.3 (7 Nov 2015 22:37:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Nov 2015 22:37:55 +0000 (UTC) Cc: Artur Malabarba , emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 07 23:37:45 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 1ZvC7C-00079W-NI for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 23:37:42 +0100 Original-Received: from localhost ([::1]:45416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvC7C-00008Q-8q for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 17:37:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvC79-00008L-33 for emacs-devel@gnu.org; Sat, 07 Nov 2015 17:37:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvC74-00042h-3T for emacs-devel@gnu.org; Sat, 07 Nov 2015 17:37:39 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:47847 helo=homiemail-a13.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvC73-00042d-U6 for emacs-devel@gnu.org; Sat, 07 Nov 2015 17:37:34 -0500 Original-Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 15185334078; Sat, 7 Nov 2015 14:37:33 -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-a13.g.dreamhost.com (Postfix) with ESMTPA id D932A334076; Sat, 7 Nov 2015 14:37:31 -0800 (PST) In-Reply-To: <20151107182420.GA1774@acm.fritz.box> (Alan Mackenzie's message of "Sat, 7 Nov 2015 18:24:21 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 69.163.253.7 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:193567 Archived-At: >> 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. > 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. > 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. Honestly, I see here nothing that requires a new multi-window framework.