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: The future of Follow Mode - a proposal. Date: Fri, 19 Feb 2016 18:18:34 +0000 Message-ID: <20160219181834.GC3193@acm.fritz.box> References: <20160218195630.GA2697@acm.fritz.box> <837fi1u5qt.fsf@gnu.org> <20160219142522.GA3193@acm.fritz.box> <83povsr8cc.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1455905789 32524 80.91.229.3 (19 Feb 2016 18:16:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Feb 2016 18:16:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 19 19:16:20 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 1aWpbI-0008Jh-Js for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 19:16:20 +0100 Original-Received: from localhost ([::1]:54419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWpbI-0007cV-0b for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 13:16:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWpbD-0007cL-O7 for emacs-devel@gnu.org; Fri, 19 Feb 2016 13:16:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWpb9-00055U-KS for emacs-devel@gnu.org; Fri, 19 Feb 2016 13:16:15 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:30991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWpb9-000552-BI for emacs-devel@gnu.org; Fri, 19 Feb 2016 13:16:11 -0500 Original-Received: (qmail 20055 invoked by uid 3782); 19 Feb 2016 18:16:10 -0000 Original-Received: from acm.muc.de (p548A4E9B.dip0.t-ipconnect.de [84.138.78.155]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 19 Feb 2016 19:16:08 +0100 Original-Received: (qmail 28740 invoked by uid 1000); 19 Feb 2016 18:18:34 -0000 Content-Disposition: inline In-Reply-To: <83povsr8cc.fsf@gnu.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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:200228 Archived-At: Hello, Eli. On Fri, Feb 19, 2016 at 06:08:35PM +0200, Eli Zaretskii wrote: > > Date: Fri, 19 Feb 2016 14:25:23 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > 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. For me, there's a noticeable delay between, say scrolling one window and the resulting scrolling in the other windows happening. There are several distinct redisplays happening, rather than the ideal of just one. But I work mostly on a Linux VT. Perhaps the delay's are less noticeable on X or win32. > > > 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. I envisage reinitialising the iterator structure as necessary when passing bewteen windows. The change in width would be handled at a relatively high level. The window start position is known, the window end position could be calculated as we progress. > 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. As in Fvertical_motion. Sometimes it will be appropriate to keep the dimensions of the "old" window (for example, when scrolling by doing `vertical-motion' followed by `set-window-start'), sometimes it won't be (for example, in `previous-line' when `line-mode-visual' is set). Fvertical_motion is difficult because it's function hasn't been unambiguously tied down (there's never been any need before). It would be necessary to classify each use of it as being either "movement within the physical window structure" or "movement within an ideal infinite height window". As an example, `compute_window_start_on_continuation_line' would have to use the dimensions of the previous window to determine the window-start. Jiggling the various windows around after text changes or scrolling is going to be the hard part of the coding. -- Alan Mackenzie (Nuremberg, Germany).