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: Fri, 19 Feb 2016 18:18:34 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Eli.

On Fri, Feb 19, 2016 at 06:08:35PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 19 Feb 2016 14:25:23 +0000
> > Cc: address@hidden
> > From: Alan Mackenzie <address@hidden>

> > > IMO, moving the code to C will solve only the marginal aspects of
> > > this.

> > It would certainly help with the speed, and likely help get a uniform
> > mode line.

> Speed is one of the marginal aspects of this, from my POV.  Follow
> mode is not terribly slow as it is.

For me, there's a noticeable delay between, say scrolling one window and
the resulting scrolling in the other windows happening.  There are
several distinct redisplays happening, rather than the ideal of just one.
But I work mostly on a Linux VT.  Perhaps the delay's are less noticeable
on X or win32.

> > > The main problem -- the fact that the current display engine doesn't
> > > support windows of unequal width -- cannot be solved without deep
> > > changes.  We need to at least design these changes first, so that we
> > > have a clear idea how to solve these issues.  FWIW, I thought about
> > > this for a while, and didn't see any easy way of doing it.

> > The display engine currently works on each window as an independent
> > entity.  It needs to understand "window groups".  Several things it now
> > does on windows (scrolling, moving point, ...) will need to be extended
> > to work on window groups.

> > Where and why do you see the need for deep changes?

> 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.  The window start position is known, the window
end position could be calculated as we progress.

> Their model is: initialize the iterator object with the metrics of the
> window, then use that for the entire iteration.  There's only one copy
> of window metrics in the iterator object.  They also assume that text
> above the window start and below its end would have been laid out using
> the same window width, something that is required when the display
> engine considers whether to scroll the window.

As in Fvertical_motion.  Sometimes it will be appropriate to keep the
dimensions of the "old" window (for example, when scrolling by doing
`vertical-motion' followed by `set-window-start'), sometimes it won't be
(for example, in `previous-line' when `line-mode-visual' is set).

Fvertical_motion is difficult because it's function hasn't been
unambiguously tied down (there's never been any need before).  It would
be necessary to classify each use of it as being either "movement within
the physical window structure" or "movement within an ideal infinite
height window".

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.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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