Re: The future of Follow Mode - a proposal.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Feb 19, 2016 at 08:45:39PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 19 Feb 2016 18:18:34 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

Or, maybe not, se below.

> > The window start position is known, the window end position could be
> > calculated as we progress.

> The functions we talk about currently don't know what they are invoked
> for.  Your envisioned changes imply that they should behave
> differently depending on whether the results will be used for layout
> of the current window or the next/previous window in a group.  That's
> part of the changes I had in mind.  They are not trivial.  But without
> them, what you want to do will not work reliably.

How about adding an extra boolean parameter to the move_it_* functions,
perhaps called `physical', which when set would mean the function would
have to adjust its iterator when crossing a window boundary, when not set
would work the same way as it currently does?  `vertical-motion' would
also need this extra &optional parameter, possibly a few other defuns,
too.

There are around 150 calls to move_it_*.  I'm guessing that most of these
would set `physical' to false, perhaps more of the ones in window.c would
use true.

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

> Yes, and the result will be non-trivial changes in the overall logic,
> because redisplaying a window will no longer be independent of other
> windows.

Yes.  This is what is currently implemented in Follow Mode.

> It's all doable, of course, but I suggest taking a good look at the
> use cases for each of these functions, before you design the way they
> should work to support windows of unequal width.

-- 
Alan Mackenzie (Nuremberg, Germany).