Re: Framework extending window functions for Follow Mode (etc.).

[Alan Mackenzie <acm@muc.de>]

Hello, Artur.

On Sat, Nov 07, 2015 at 05:54:20PM +0000, Artur Malabarba wrote:
> On 5 Nov 2015 7:29 pm, "Alan Mackenzie" <acm@muc.de> wrote:
> Hi Alan,

> > Partly out of a need to nail down bug #17453, partly out of a need to
> > make it easier for arbitrary libraries to work with Follow Mode, partly
> > at the suggestion of Eli, I now propose the following.

> > The six functions window-start, window-end, set-window-start, recenter,
> > pos-visible-in-window-p, and move-to-window-line-function will acquire
> > an extra optional parameter GROUP.  The notion is that "this call is
> > interested in groups of windows, not just single ones".

> I admit I am confused. I thought we had narrowed down three possible
> solutions to this issue (which you just listed over at the bug thread), all
> of which are simpler than this code.

Those solutions are to merely one part of the bug, namely C-s wrongly
scrolling a window instead of moving onto the next one.

The other parts of #17453 are:
2: lazy highlighting is confined to one Follow Mode window (I'm a bit
  confused as to the status of this, though);
3: With isearch-allow-scroll enabled, it is not possible to scroll point
  to the next or previous Follow Mode window;
, in addition to which I have a fix for ...
4: With point near the bottom of a Follow Mode window, start an Isearch,
  and repeatedly do M-s C-e, until the highlighted match continues on to
  the next window.  Continue doing M-s C-e until the string in the
  minibuffer expands by a line.  At this point the top of the RH window
  gets spuriously scrolled into the middle of the window, leaving the FM
  windows unsynchronised.

> Is this functionality here still necessary to fix that bug?

It needed to fix items 2, 3, and 4.

Sorry for causing this confusion.

-- 
Alan Mackenzie (Nuremberg, Germany).