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: The future of Follow Mode - a proposal. Date: Thu, 18 Feb 2016 19:56:30 +0000 Message-ID: <20160218195630.GA2697@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1455825286 7949 80.91.229.3 (18 Feb 2016 19:54:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Feb 2016 19:54:46 +0000 (UTC) To: Anders Lindgren , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 18 20:54:37 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 1aWUep-0005gR-RW for ged-emacs-devel@m.gmane.org; Thu, 18 Feb 2016 20:54:35 +0100 Original-Received: from localhost ([::1]:44911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWUep-0006fe-57 for ged-emacs-devel@m.gmane.org; Thu, 18 Feb 2016 14:54:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49211) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWUeR-0006ek-Q6 for emacs-devel@gnu.org; Thu, 18 Feb 2016 14:54:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWUeO-0002Lk-G9 for emacs-devel@gnu.org; Thu, 18 Feb 2016 14:54:11 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:30998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWUeO-0002Kv-6N for emacs-devel@gnu.org; Thu, 18 Feb 2016 14:54:08 -0500 Original-Received: (qmail 87828 invoked by uid 3782); 18 Feb 2016 19:54:06 -0000 Original-Received: from acm.muc.de (p548A4834.dip0.t-ipconnect.de [84.138.72.52]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 18 Feb 2016 20:54:05 +0100 Original-Received: (qmail 2721 invoked by uid 1000); 18 Feb 2016 19:56:30 -0000 Content-Disposition: inline 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:200153 Archived-At: Hello, Anders and Emacs. Although Follow Mode has served extremely well for several decades, it has several shortcomings which make it less good than it might be: (i) It is not particularly fast - synchronising the several pertinent windows can take several tenths of a second, even on modern hardware. One reason for this is that Follow Mode and the display engine fight eachother, and several strategems which are necessary for FM to win (such as explicitly calling `redisplay' from the post-command-hook) are nevertheless suboptimal. (ii) Where adjacent windows are of unequal width (this is the normal case), a continued line is displayed incorrectly when it straddles two windows: either one or more characters are displayed twice, or they are not displayed at all (depending on which window is the wider one). This is extraordinarily difficult to fix with the current display engine and follow.el. (iii) Each Follow Mode window has its own individual mode line, although Follow Mode's aim is to create the illusion of a single multi-column window. Often important info is truncated, due to the narrowness of a typical FM window. It would be better to have a single mode line stretching across the entire screen. I propose moving much of Follow Mode's mechanism into our C code, in particular, into window.c and xdisp.c. In window.c/h would appear a new `struct wgroup' which would administer Follow Mode window groups. It would contain details of the buffer it's administering, the frame, and pointers to the first and last of the FM windows. `struct window' would be amended to contain forward and backward links, allowing us to create a chain of the FM windows, also to contain a pointer to the wgroup. In addition, `struct wgroup' would note which of its windows is the current/active one. Also in window.c would come infrastructure for creating and administering `struct wgroups'. Such functions as `pop-to-buffer' would typically need to remove a window from the `struct wgroup' before repurposing it for the new buffer. The first shock: `select-window' would be amended, such that attempting to select any window in a wgroup would result in the current/active window in the group actually being selected instead. This would go a long way towards maintaining the illusion of a single multi-column window. An additional &optional parameter would be given to `select-window' meaning "select THIS window, no matter what", for the use of lower level routines. `vertical-motion' would need a substantial rethink, since it would have to work in a "window" whose width varies. There will likely be several other such functions needing amendment. But not many. Most of the difficult work would be within xdisp.c. Any form of scrolling is going to be tricky to implement, as indeed it is in follow.el. Moving over the boundary of two windows will mean (?)xdisp.c having to select-window where it currently scrolls a window. More generally, the scrolling/point-moving bits would need to be amended. Creating a unified mode line seems tricky, given the way it's currently done in xdisp.c. (It merely reserves the final line of the window, and writes there.) There may be better ways to achieve the single mode line, but one way would be to implement mode lines as windows in their own right, thus giving them scope to be somewhere else other than squashed up into a window's last line. This would also enable several FM windows to share a single mode line. Comments? -- Alan Mackenzie (Nuremberg, Germany).