Re: The future of Follow Mode - a proposal.

[Alan Mackenzie]

Hello, Eli.

On Fri, Feb 19, 2016 at 06:30:01PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 19 Feb 2016 15:56:22 +0100
> > From: Anders Lindgren <address@hidden>
> > Cc: Alan Mackenzie <address@hidden>, emacs-devel <address@hidden>

> > Windows of unequal width is something that we need to live with, at
> > least if follow-mode is something that a user can enable without
> > affecting the layout of a frame, like today.

> My suggestion is that enabling the mode will equalize the width of all
> the windows under Follow mode.

This would sort of work in the usual case, but in the general case,
arbitrary windows, not necessarily covering a nice rectangular area would
be involved.  It is not simple to adjust such an arbitrary set to make
them all the same width.

> > Anyway, wouldn't it be possible for the display engine to do the
> > layout of the leftmost window (of a follow mode window group) using
> > the normal system for finding a suitable start location on even line
> > boundaries. The rest of the windows in the window group could then
> > use the end position of the previous window.

> This would mean the order in which we display windows will have to be
> forced to follow the Follow mode order.  Moreover, it would mean that
> the decisions of whether to redisplay a certain window will now have
> to consider other windows, something that doesn't happen today.

It doesn't happen in the display engine, no, but it happens at the Lisp
level in Follow Mode.  It would be more efficient in every sense if it
were actually done by the display engine.

> Moreover, the starting point of the window is just the tip of the
> iceberg.  The display engine uses the move_it_* family of functions to
> decide where the window starts and ends, when to scroll the window,
> whether point is visible or not, etc.  We also use these functions for
> user-level window scrolling and in vertical-motion.  All of that code
> assumes that the window width doesn't change beyond window edges.
> Invalidating this assumption wreaks havoc in many places, so these
> functions will have to be rewritten to take the fact that text in the
> next window uses a different width.  See the discussion of
> vertical-motion we had with Alan several months ago --

:-)  I've still got the code somewhere which allows an arbitrary
window-start to be set.  That wasn't the difficult bit.

> while working on the patch I presented there, I realized that this
> feature is unworkable as long as the display engine was not taught to
> handle unequal-width windows.

The display engine would need to handle window _groups_.  The variable
width part would be part of this.

> > In fact, I think it could be supported today from lisp if only it was
> > possible to disable the part of the display engine that ensures that
> > the window start position is an even multiple of the window width, on
> > a window-by-window basis. In the case of follow-mode, the leftmost
> > window should keep it enabled, whereas the rest should disable this
> > feature.

I tried that last autumn.  It was more complicated than I'd imagined.

> The current display engine likes the window start point to be at the
> beginning of a physical line.  Lifting this restriction also requires
> changes, because currently, even if you trick the display into using a
> starting point in the middle of a line, it is likely to reset that to
> the line beginning on the next redisplay cycle.

This will cease to be a problem if the display engine can handle window
groups.  The display engine already allows windows to start in
continuation lines.  It's just how you calculate the start of such a
line.

> IOW, without changes in the display engine, we will be making a series
> of questionable kludges one upon the other.  That's hardly the way to
> develop Emacs.

> I understand the desire to avoid significant changes in the design of
> the display engine, but I see no way this could work reliably, unless
> we force all the Follow-mode windows to be of equal width (in
> character units).

I agree that the display engine would need significant modification.

> > (The only thing that wouldn't work is if a multi-width character
> > (like control-l "^L") is partially visible. It will continue to work
> > like today, with "^" visible at the end of one window and "^L" at the
> > start of the next.)

> Control characters are not the only ones which will bump into this.

This surely occurs already, and might not be relevant to the exercise.

-- 
Alan Mackenzie (Nuremberg, Germany).