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

[Juri Linkov <juri@linkov.net>]

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

This problem is already solved by enabling lazy-highlighting of the whole
follow-mode buffer, but I postponed installing that patch to not create merge
conflicts with your work in the same functions.

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

That's because isearch-post-command-hook uses isearch-pre-scroll-point
to move it back, so it's possible to nullify isearch-pre-scroll-point
in follow-mode, but I see that it leaves the highlighted found string
at its old position because the isearch-allow-scroll feature doesn't support
finding the next search hit after scrolling, or something like this
that would make sense.  IOW, this is a limitation of isearch-allow-scroll.

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

I see the same behavior even without Isearch.

Honestly, I see here nothing that requires a new multi-window framework.