The future of Follow Mode - a proposal.

[Alan Mackenzie]

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).