emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The future of Follow Mode - a proposal.


From: Alan Mackenzie
Subject: Re: The future of Follow Mode - a proposal.
Date: Sat, 20 Feb 2016 12:44:15 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

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: address@hidden
> > From: Alan Mackenzie <address@hidden>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]