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 14:25:23 +0000 Message-ID: <20160219142522.GA3193@acm.fritz.box> References: <20160218195630.GA2697@acm.fritz.box> <837fi1u5qt.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 1455891815 4038 80.91.229.3 (19 Feb 2016 14:23:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Feb 2016 14:23:35 +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 15:23:26 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 1aWlxt-0004vH-SU for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 15:23:26 +0100 Original-Received: from localhost ([::1]:52725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlxt-0004Xw-4m for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 09:23:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlxY-0004Ww-DF for emacs-devel@gnu.org; Fri, 19 Feb 2016 09:23:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWlxV-0005sA-7a for emacs-devel@gnu.org; Fri, 19 Feb 2016 09:23:04 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:14670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWlxU-0005re-U9 for emacs-devel@gnu.org; Fri, 19 Feb 2016 09:23:01 -0500 Original-Received: (qmail 65773 invoked by uid 3782); 19 Feb 2016 14:22:58 -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 15:22:57 +0100 Original-Received: (qmail 10551 invoked by uid 1000); 19 Feb 2016 14:25:23 -0000 Content-Disposition: inline In-Reply-To: <837fi1u5qt.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:200212 Archived-At: 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. > 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? > If we abandon the design goal of supporting windows of unequal width, > the problem becomes much easier. Yes, but that's not realistic, I think. Follow Mode windows _are_ of unequal width. > I suggest to talk about these main issues first, and only move further > with any kind of implementation once we've resolved this. The > decision of what to keep in Lisp and what to move to C is also > meaningful only after resolving these main issues. Again, could you list the issues in somewhat more detail, please? A trouble with projects like this one is that they can hover unendlessly at a very high level of abstraction, too high for much progress to be made. This is why I sketched out in some detail an approach to getting things done. -- Alan Mackenzie (Nuremberg, Germany).