From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: The future of Follow Mode - a proposal. Date: Fri, 19 Feb 2016 18:08:35 +0200 Message-ID: <83povsr8cc.fsf@gnu.org> References: <20160218195630.GA2697@acm.fritz.box> <837fi1u5qt.fsf@gnu.org> <20160219142522.GA3193@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1455898154 18201 80.91.229.3 (19 Feb 2016 16:09:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Feb 2016 16:09:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 19 17:09:13 2016 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 1aWncG-0007YH-Oq for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 17:09:12 +0100 Original-Received: from localhost ([::1]:53419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWncF-0005Wf-U1 for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 11:09:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWnbx-0005W5-N0 for emacs-devel@gnu.org; Fri, 19 Feb 2016 11:08:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWnbr-0002Al-Uh for emacs-devel@gnu.org; Fri, 19 Feb 2016 11:08:53 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWnbr-0002Ag-RE; Fri, 19 Feb 2016 11:08:47 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3941 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aWnbr-0003qv-0x; Fri, 19 Feb 2016 11:08:47 -0500 In-reply-to: <20160219142522.GA3193@acm.fritz.box> (message from Alan Mackenzie on Fri, 19 Feb 2016 14:25:23 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:200220 Archived-At: > Date: Fri, 19 Feb 2016 14:25:23 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > Hello, Eli. > > On Thu, Feb 18, 2016 at 10:24:10PM +0200, Eli Zaretskii wrote: > > > Date: Thu, 18 Feb 2016 19:56:30 +0000 > > > From: Alan Mackenzie > > > > > > I propose moving much of Follow Mode's mechanism into our C code, in > > > particular, into window.c and xdisp.c. > > > IMO, moving the code to C will solve only the marginal aspects of > > this. > > It would certainly help with the speed, and likely help get a uniform > mode line. Speed is one of the marginal aspects of this, from my POV. Follow mode is not terribly slow as it is. > > The main problem -- the fact that the current display engine doesn't > > support windows of unequal width -- cannot be solved without deep > > changes. We need to at least design these changes first, so that we > > have a clear idea how to solve these issues. FWIW, I thought about > > this for a while, and didn't see any easy way of doing it. > > The display engine currently works on each window as an independent > entity. It needs to understand "window groups". Several things it now > does on windows (scrolling, moving point, ...) will need to be extended > to work on window groups. > > Where and why do you see the need for deep changes? I already explained this above: "the fact that the current display engine doesn't support windows of unequal width". If you want to lift this limitation, the move_it_* family of functions, which simulate redisplay, and are the workhorse of every decision Emacs makes that concerns layout, cannot switch windows in their inner loops. Their model is: initialize the iterator object with the metrics of the window, then use that for the entire iteration. There's only one copy of window metrics in the iterator object. They also assume that text above the window start and below its end would have been laid out using the same window width, something that is required when the display engine considers whether to scroll the window.