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

[Alan Mackenzie]

Hello, Juri.

On Sat, Nov 07, 2015 at 11:58:29PM +0200, Juri Linkov wrote:
> >> 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.

My solution is to lazily highlight just the part visible in windows (but
in all pertinent windows).  Isn't highlighting all of it going to be a
bit slow on a large buffer?

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

In my personal copy of Emacs, I've had the isearch scrolling working
properly with Follow Mode for ~18 months.  It was me that wrote the
isearch scrolling code in the first place, back in 2003.  Part 3 of the
bug is most assuredly NOT an intrinsic limitation of
isearch-allow-scroll.  It's caused by the variables w-L1 and w-L-1, the
bounds for the permissible scrolling range in
isearch-string-out-of-window, being set to the top and botom of the
_single_ window.  When these variables are set to the top of bottom of
the entire FM group of windows, the bug is solved.  This requires my new
framework, or something like it.

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

The buggy behaviour I've described is explicitly and essentially an
Isearch scenario.  What do you mean by "the same behavior" and what
sequence of commands generates it?

The solution to problem 4 involves making sure point is at the right
place at the right time when invoking isearch-message.  I have made
changes to fix it.

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

I want these bugs to be solved.  What, then, are the alternatives to
this framework (or something like it)?  Isearch needs information about
the Follow Mode windows, or it can't work properly.

So far, I've written three solutions for these bugs, as I outlined at
length in an email to Martin R. today.  The first of these solutions was
(justifiably) rejected by Stefan because it was a quick and dirty fix,
and he explicitly requested the new framework that I have now built.
Eli didn't like the second attempt and explicitly suggested the way for
my third attempt.  You and Martin dislike this most recent third
attempt.

It seems to me I've spent more time discussing this bug on the bug list
and emacs-devel, and reformulating the fix, than actually tracking down
and fixing the bugs in the first place.  At the moment I feel like I'm
trying to hack down a wall of constant negativity.  I don't recall
anybody else saying positively they want this bug fixed, and I certainly
don't feel I've had much encouragement wrt this bug, in the last few
days and weeks.

I see Follow Mode as being a critically important component of Emacs,
the more so since very wide (240 characters and more) screens displaced
the fairly narrow CRT monitors.  I would like every Emacs user to be
able to use FM as easily as I can.  Right at the moment there is no
suitable interface to FM for libraries that require to do their own
window manipulation.  Such an interface is what Stefan wanted, and it's
what I want, too.  As of yet, there's been practically no discussion of
this interface I've written, beyond Eli suggesting the current version
and John suggesting a name change for some hooks.

So, where do we go from here?  I would like these bugs fixed for 25.1.

-- 
Alan Mackenzie (Nuremberg, Germany).