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

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

[Alan Mackenzie]

Hello, Emacs.

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

Each of these functions will get an associated variable, e.g.
"window-start-function".  The function will call the value of that
variable instead of doing its normal actions, when GROUP is non-nil.
Typically, the `window-start-function' will recursively call
window-start (on some window) to perform its operation.

window-start-function, and friends, will be set by Follow Mode in its
initialisation, and unset when it is disabled.

Here is one sixth of the patch for this change (excluding changes to the
manual).  As a patch, it probably won't work because of all the
deletions.  (The whole of the patch would quickly become tedious.)



diff --git a/src/window.c b/src/window.c
index d61f586..46adda7 100644
--- a/src/window.c
+++ b/src/window.c
@@ -1655,30 +1671,39 @@ Return POS.  */)
   return pos;
 }
 
-DEFUN ("set-window-start", Fset_window_start, Sset_window_start, 2, 3, 0,
+DEFUN ("set-window-start", Fset_window_start, Sset_window_start, 2, 4, 0,
        doc: /* Make display in WINDOW start at position POS in WINDOW's buffer.
 WINDOW must be a live window and defaults to the selected one.  Return
 POS.  Optional third arg NOFORCE non-nil inhibits next redisplay from
-overriding motion of point in order to display at this exact start.  */)
-  (Lisp_Object window, Lisp_Object pos, Lisp_Object noforce)
+overriding motion of point in order to display at this exact start.
+
+If GROUP is non-nil, and `set-window-start-function' is set to a function,
+then instead of the above, that function is called with the three arguments
+WINDOW, POS, and NOFORCE, and its result returned.  */)
+  (Lisp_Object window, Lisp_Object pos, Lisp_Object noforce, Lisp_Object group)
 {
-  register struct window *w = decode_live_window (window);
+  if (!NILP (group)
+      && FUNCTIONP (Vset_window_start_function))
+    return call3 (Vset_window_start_function, window, pos, noforce);
+  {
+    register struct window *w = decode_live_window (window);
 
-  set_marker_restricted (w->start, pos, w->contents);
-  /* This is not right, but much easier than doing what is right.  */
-  w->start_at_line_beg = false;
-  if (NILP (noforce))
-    w->force_start = true;
-  w->update_mode_line = true;
-  /* Bug#15957.  */
-  w->window_end_valid = false;
-  wset_redisplay (w);
+    set_marker_restricted (w->start, pos, w->contents);
+    /* This is not right, but much easier than doing what is right.  */
+    w->start_at_line_beg = false;
+    if (NILP (noforce))
+      w->force_start = true;
+    w->update_mode_line = true;
+    /* Bug#15957.  */
+    w->window_end_valid = false;
+    wset_redisplay (w);
 
-  return pos;
+    return pos;
+  }
 }
 
 DEFUN ("pos-visible-in-window-p", Fpos_visible_in_window_p,
@@ -7159,7 +7212,15 @@ syms_of_window (void)
   DEFSYM (Qclone_of, "clone-of");
   DEFSYM (Qfloor, "floor");
   DEFSYM (Qceiling, "ceiling");
-
+  DEFSYM (Qwindow_start_function, "window-start-function");
+  DEFSYM (Qwindow_end_function, "window-end-function");
+  DEFSYM (Qset_window_start_function, "set-window-start-function");
+  DEFSYM (Qrecenter_function, "recenter-function");
+  DEFSYM (Qpos_visible_in_window_p_function, "pos-visible-in-window-p-function");
+  DEFSYM (Qmove_to_window_line_function, "move-to-window-line-function");
+  
   staticpro (&Vwindow_list);
 
   minibuf_selected_window = Qnil;
@@ -7330,6 +7391,70 @@ Note that this optimization can cause the portion of the buffer
+  DEFVAR_LISP ("set-window-start-function", Vset_window_start_function,
+               doc: /* The function to call for `set-window-start' when its GROUP parameter is non-nil.
+When this variable contains a function, and `set-window-start' is called
+with a non-nil GROUP parameter, the function is called instead of
+`set-window-start''s normal action.  `set-window-start' passes the function
+its three parameters WINDOW, POS, and NOFORCE.  The function may call
+`set-window-start' recursively.  */);
+  Vset_window_start_function = Qnil;
+  Fmake_variable_buffer_local (Qset_window_start_function);
+  Fput (Qset_window_start_function, Qpermanent_local, Qt);
+



-- 
Alan Mackenzie (Nuremberg, Germany).

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

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

> Each of these functions will get an associated variable, e.g.
> "window-start-function".  The function will call the value of that
> variable instead of doing its normal actions, when GROUP is non-nil.
> Typically, the `window-start-function' will recursively call
> window-start (on some window) to perform its operation.

This is unrelated to the material content of your patch, but I'd call this
window-start-group-function, since it's not really the "function that goes to
window start", but the "function that goes to window start when groups are to
be considered".

John

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

[Alan Mackenzie]

Hello, John.

On Thu, Nov 05, 2015 at 02:36:40PM -0500, John Wiegley wrote:
> >>>>> Alan Mackenzie <acm@muc.de> writes:

> > Each of these functions will get an associated variable, e.g.
> > "window-start-function".  The function will call the value of that
> > variable instead of doing its normal actions, when GROUP is non-nil.
> > Typically, the `window-start-function' will recursively call
> > window-start (on some window) to perform its operation.

> This is unrelated to the material content of your patch, but I'd call this
> window-start-group-function, since it's not really the "function that goes to
> window start", but the "function that goes to window start when groups are to
> be considered".

Thanks, that's an excellent idea.  It's so easy to miss things like that
when embroiled in something tedious.

> John

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Emacs.

On Thu, Nov 05, 2015 at 07:29:05PM +0000, Alan Mackenzie wrote:
> 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".

> Each of these functions will get an associated variable, e.g.
> "window-start-function".  The function will call the value of that
> variable instead of doing its normal actions, when GROUP is non-nil.
> Typically, the `window-start-function' will recursively call
> window-start (on some window) to perform its operation.

Now renamed to "window-start-group-function", at John's suggestion.

> window-start-function, and friends, will be set by Follow Mode in its
> initialisation, and unset when it is disabled.

I've now updated the requisite two pages in Elisp.

This suggestion doesn't seem to have sparked off too much debate.  Can I
take it that people are generally happy about it?  In that case, I will
commit the change.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > 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".
 >
 > Each of these functions will get an associated variable, e.g.
 > "window-start-function".  The function will call the value of that
 > variable instead of doing its normal actions, when GROUP is non-nil.
 > Typically, the `window-start-function' will recursively call
 > window-start (on some window) to perform its operation.

Instead of an extra argument I would prefer to have these functions
check for the presence of a ‘window-start’, ‘window-end’, ... window
parameter just like ‘delete-window’ or ‘other-window’ do.

martin

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

[Alan Mackenzie]

Hello, Martin.

On Sat, Nov 07, 2015 at 02:26:16PM +0100, martin rudalics wrote:
>  > 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".

>  > Each of these functions will get an associated variable, e.g.
>  > "window-start-function".  The function will call the value of that
>  > variable instead of doing its normal actions, when GROUP is non-nil.
>  > Typically, the `window-start-function' will recursively call
>  > window-start (on some window) to perform its operation.

> Instead of an extra argument I would prefer to have these functions
> check for the presence of a ‘window-start’, ‘window-end’, ... window
> parameter just like ‘delete-window’ or ‘other-window’ do.

I don't think that would be the Right Thing (if I've understood it
properly, that is).  With Follow Mode active, which window start
window-start returns is primarily about the context of the window-start
invocation; it's not about some windows always doing one thing, some
always doing another.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > I don't think that would be the Right Thing (if I've understood it
 > properly, that is).  With Follow Mode active, which window start
 > window-start returns is primarily about the context of the window-start
 > invocation; it's not about some windows always doing one thing, some
 > always doing another.

I don't understand why we would want to hardcode a GROUP argument.  When
we encounter a similar problem with foo-mode what are we supposed to do?
Use the GROUP argument?  Add a FOO argument?

martin

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

[Alan Mackenzie]

Hello, Martin.

On Sat, Nov 07, 2015 at 04:18:18PM +0100, martin rudalics wrote:
>  > I don't think that would be the Right Thing (if I've understood it
>  > properly, that is).  With Follow Mode active, which window start
>  > window-start returns is primarily about the context of the window-start
>  > invocation; it's not about some windows always doing one thing, some
>  > always doing another.

> I don't understand why we would want to hardcode a GROUP argument.

It would appear to be a good way of solving the immediate problem, that
is, of being able to address a Follow Mode group of windows and a single
window in a unified fashion.  It thus avoids having explicitly to code
Follow Mode stuff into random .el (or .c) files.

The immediate use case is in Isearch, where currently Isearch doesn't
play well with Follow Mode.  See the stuff relating to bug #17453 in
debbugs.

> When we encounter a similar problem with foo-mode what are we supposed
> to do?  Use the GROUP argument?  Add a FOO argument?

Yes, I would say.  I'm guessing your concern is that such arguments on
some functions could proliferate, giving an unmanageable number of
them.  But what is the likelihood of this happening?  Or, in particular,
of it happening to these particular window handling functions?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > Yes, I would say.  I'm guessing your concern is that such arguments on
 > some functions could proliferate, giving an unmanageable number of
 > them.  But what is the likelihood of this happening?  Or, in particular,
 > of it happening to these particular window handling functions?

I can't tell.  But adding a special argument to six primitives for
handling one particular case in the interaction between isearch and
follow mode already appears like a proliferation to me.

If the peculiar behavior is tied to isearch, then I have no idea why you
can't devise a function like ‘isearch-set-window-start’ and special code
the follow mode behavior there.

martin

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

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On 5 Nov 2015 7:29 pm, "Alan Mackenzie" <acm@muc.de> wrote:
>
> Hello, Emacs.

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.
Is this functionality here still necessary to fix that bug?

[-- Attachment #2: Type: text/html, Size: 1030 bytes --]

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

[Alan Mackenzie]

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

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

[Alan Mackenzie]

Hello, Martin.

On Sat, Nov 07, 2015 at 06:07:35PM +0100, martin rudalics wrote:
>  > Yes, I would say.  I'm guessing your concern is that such arguments on
>  > some functions could proliferate, giving an unmanageable number of
>  > them.  But what is the likelihood of this happening?  Or, in particular,
>  > of it happening to these particular window handling functions?

> I can't tell.  But adding a special argument to six primitives for
> handling one particular case in the interaction between isearch and
> follow mode already appears like a proliferation to me.

A bit about the history of bug #17453: I've presented three solutions so
far, and none has met with universal approval.

The first one, ~18 months ago, simply adapted isearch.el making direct
calls to Follow Mode's functions.  This was rejected by Stefan, who
asked for a more general solution, one that would enable other libraries
to access Follow Mode more easily.  In his own words,

> IOW we should try harder to come up with more general hooks.

What Stefan asked for is what you are criticising here.

The second attempt, a week or two ago, invented new functions with new
names to perform the functions of `window-start' etc., on either a
group of windows or a single window.  Eli criticised this, saying:

> Btw, I see no reason to introduce new functions.  Instead, we could
> have the original ones accept an additional optional argument.

The third attempt, yesterday/today, was in response to that comment from
Eli.

> If the peculiar behavior is tied to isearch, then I have no idea why you
> can't devise a function like ‘isearch-set-window-start’ and special code
> the follow mode behavior there.

Because the behaviour isn't to be restricted to isearch.  Also, the
facilities needed from Follow mode far exceed what could be sensibly
coded in such a function.  In any case, what you're suggesting is pretty
much my second solution attempt, which created six functions like
`set-window*-start', but restricted to Isearch.

There are currently up to 132 occurrences of set-window-start in the
lisp sources.  Some of these would likely be more useful if they took
into account FM, and called set-window-start with the GROUP argument
non-nil.  These latest changes of mine would allow any such library to
be quickly adapted for Follow Mode.

Also, were Follow Mode to be superseded at any time, then the interface
I'm proposing would not need adapting to FM's successor.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Juri Linkov]

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

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

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

[martin rudalics]

 > A bit about the history of bug #17453: I've presented three solutions so
 > far, and none has met with universal approval.
 >
 > The first one, ~18 months ago, simply adapted isearch.el making direct
 > calls to Follow Mode's functions.  This was rejected by Stefan, who
 > asked for a more general solution, one that would enable other libraries
 > to access Follow Mode more easily.

I don't think that other libraries should pay attention to Follow Mode.

 > In his own words,
 >
 >> IOW we should try harder to come up with more general hooks.
 >
 > What Stefan asked for is what you are criticising here.

Why do you think so?  You want to give ‘set-window-start’ an additional,
optional argument GROUP.  If it's non-nil, ‘set-window-start’ should
call the function stored in ‘set-window-start-function’.  Correct so
far?

If so, then how comes that this argument is called "GROUP"?  An argument
with such a name should be non-nil only in calls by ‘follow-mode’ or
other packages that know that WINDOW is part of some "group".
‘isearch-mode’ has no idea whether WINDOW is part of a group and should
not have to.  OTOH somebody might want ‘set-window-start’ to behave
specially even when WINDOW is not part of a group.

For me a general solution means that any mode that forms a group of
windows (like ‘follow-mode’) adds window parameters to all windows that
are part of that group.  And any function like ‘set-window-start’ that
should behave specially when the window it operates on is part of a
group of windows will have to inspect that parameter (and maybe other
parameters as well).

 > The second attempt, a week or two ago, invented new functions with new
 > names to perform the functions of `window-start' etc., on either a
 > group of windows or a single window.  Eli criticised this, saying:
 >
 >> Btw, I see no reason to introduce new functions.  Instead, we could
 >> have the original ones accept an additional optional argument.

Above I explained why IMO the new argument is not about "groups".

 > The third attempt, yesterday/today, was in response to that comment from
 > Eli.
 >
 >> If the peculiar behavior is tied to isearch, then I have no idea why you
 >> can't devise a function like ‘isearch-set-window-start’ and special code
 >> the follow mode behavior there.
 >
 > Because the behaviour isn't to be restricted to isearch.  Also, the
 > facilities needed from Follow mode far exceed what could be sensibly
 > coded in such a function.  In any case, what you're suggesting is pretty
 > much my second solution attempt, which created six functions like
 > `set-window*-start', but restricted to Isearch.

Why such a conclusion?  Window parameters are far more flexible than
arguments.

 > There are currently up to 132 occurrences of set-window-start in the
 > lisp sources.  Some of these would likely be more useful if they took
 > into account FM,

I fully agree here ...

 > and called set-window-start with the GROUP argument
 > non-nil.

... and fully disagree here.  All these calls should be completely
unaware of whether ‘follow-mode’ is active or not.  How
‘set-window-start’ behaves would be encapsulated in the special function
prescribed by the ‘set-window-start’ parameter.

 > These latest changes of mine would allow any such library to
 > be quickly adapted for Follow Mode.

There should be no need for a library to adapt to Follow Mode.

 > Also, were Follow Mode to be superseded at any time, then the interface
 > I'm proposing would not need adapting to FM's successor.

The interface you propose already needs adapting up to 132 libraries to
FM.

martin

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

[martin rudalics]

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

Disagreed.  But _maybe_ Isearch may have to accept the fact that a
function like ‘set-window-start’ did not behave as expected.  Hopefully,
the substitute did something reasonable instead.

 > 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 want this bug fixed and would like to give you all the encouragement
you need.  But you rejected the use of window parameters without telling
me why they are inappropriate in this particular case.

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

I don't want such an interface.  Other libraries should never have to be
aware of Follow Mode.

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

Me too.

martin

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

[Alan Mackenzie]

Hello, Martin.

On Sun, Nov 08, 2015 at 10:22:44AM +0100, martin rudalics wrote:
>  > A bit about the history of bug #17453: I've presented three solutions so
>  > far, and none has met with universal approval.

>  > The first one, ~18 months ago, simply adapted isearch.el making direct
>  > calls to Follow Mode's functions.  This was rejected by Stefan, who
>  > asked for a more general solution, one that would enable other libraries
>  > to access Follow Mode more easily.

> I don't think that other libraries should pay attention to Follow Mode.

>  > In his own words,

>  >> IOW we should try harder to come up with more general hooks.

>  > What Stefan asked for is what you are criticising here.

> Why do you think so?  You want to give ‘set-window-start’ an additional,
> optional argument GROUP.  If it's non-nil, ‘set-window-start’ should
> call the function stored in ‘set-window-start-function’.  Correct so
> far?

Well, it's now been renamed `set-window-start-group-function', but
basically, yes.  The caller would call `set-window-start' without having
to know whether FM is active or not.

> If so, then how comes that this argument is called "GROUP"?

The idea is that a general package, like isearch, can call

    (set-window-start win ws nil 'group)

and this will do the Right Thing regardless of whether Follow Mode (or
whatever) is active or not.  GROUP non-nil just says "work on the whole
group of windows if there is one".

> An argument with such a name should be non-nil only in calls by
> ‘follow-mode’ or other packages that know that WINDOW is part of some
> "group".

Absolutely the reverse.  See above.  Actually, most calls from Follow
Mode, which will be about rearranging the individual windows, will be
called with GROUP set to nil.

> ‘isearch-mode’ has no idea whether WINDOW is part of a group and should
> not have to.

By my proposal, it wouldn't have to.  But it would have to be aware of
the possibility.

> OTOH somebody might want ‘set-window-start’ to behave specially even
> when WINDOW is not part of a group.

This sounds a bit hypothetical.  Do you have an example of the sort of
thing this might be?

> For me a general solution means that any mode that forms a group of
> windows (like ‘follow-mode’) adds window parameters to all windows that
> are part of that group.  And any function like ‘set-window-start’ that
> should behave specially when the window it operates on is part of a
> group of windows will have to inspect that parameter (and maybe other
> parameters as well).

I think what you mean is that `set-window-start' would first test the
window-parameter, and if that is a function, would call the function
instead of doing set-window-start's normal stuff.

The problem I see with that is that when some code wants to set the
window start of an individual window, it's going to have to do something
like this:

    (let ((save-ws-param (window-parameter win 'set-window-start)))
      (set-window-parameter win 'window-start nil)
      (set-window-start win ws)
      (set-window-parameter win 'window-start save-ws-param))

, which is rather clumsy.  In fact, the situation almost calls for a
macro which would look something like:

    (with-window-parameters-set win '((set-window-start . nil))
      (set-window-start win ws))

, but even this isn't very pretty.

>  > The second attempt, a week or two ago, invented new functions with new
>  > names to perform the functions of `window-start' etc., on either a
>  > group of windows or a single window.  Eli criticised this, saying:

>  >> Btw, I see no reason to introduce new functions.  Instead, we could
>  >> have the original ones accept an additional optional argument.

> Above I explained why IMO the new argument is not about "groups".

I still think it is.

>  > The third attempt, yesterday/today, was in response to that comment from
>  > Eli.

>  >> If the peculiar behavior is tied to isearch, then I have no idea why you
>  >> can't devise a function like ‘isearch-set-window-start’ and special code
>  >> the follow mode behavior there.

>  > Because the behaviour isn't to be restricted to isearch.  Also, the
>  > facilities needed from Follow mode far exceed what could be sensibly
>  > coded in such a function.  In any case, what you're suggesting is pretty
>  > much my second solution attempt, which created six functions like
>  > `set-window*-start', but restricted to Isearch.

> Why such a conclusion?  Window parameters are far more flexible than
> arguments.

But the criterion as to whether a `set-window-start' call wants to
operate on an individual window or the group (if there is one) would be
attached to the window rather than to the call.  I don't think this is
right.

>  > There are currently up to 132 occurrences of set-window-start in the
>  > lisp sources.  Some of these would likely be more useful if they took
>  > into account FM,

> I fully agree here ...

>  > and called set-window-start with the GROUP argument
>  > non-nil.

> ... and fully disagree here.  All these calls should be completely
> unaware of whether ‘follow-mode’ is active or not.

They cannot be.  They are packages which do their own window
manipulation, and so will have to make up their minds whether a
particular `window-start' or `pos-visiblie-in-window-p' refers to an
individual window or to the group (if any).  This distinction is
essentially encapsulated in the package.  It is more convenient for a
package to set an optional parameter to nil or non-nil than to have to
"bind" a window parameter to nil.

> How ‘set-window-start’ behaves would be encapsulated in the special
> function prescribed by the ‘set-window-start’ parameter.

>  > These latest changes of mine would allow any such library to
>  > be quickly adapted for Follow Mode.

> There should be no need for a library to adapt to Follow Mode.

Distorting your meaning for a paragraph: Under my proposal, there is no
urgent need to update any package which uses `set-window-start' and
friends.  If it currently fails to work well with FM, it will continue to
work just the same until somebody amends it.  Your proposal is more
radical: we'd have to check each of the 124 uses of
`pos-visible-in-window-p' to make sure they actually should work on
entire window groups.  I would guess most of them will, but some won't.
It would, of course, also affect external code.

>  > Also, were Follow Mode to be superseded at any time, then the interface
>  > I'm proposing would not need adapting to FM's successor.

> The interface you propose already needs adapting up to 132 libraries to
> FM.

No.  There is no need, see above, even though it would be beneficial.
With your proposal, we'd need to check a lot of code.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > Well, it's now been renamed `set-window-start-group-function', but
 > basically, yes.  The caller would call `set-window-start' without having
 > to know whether FM is active or not.
 >
 >> If so, then how comes that this argument is called "GROUP"?
 >
 > The idea is that a general package, like isearch, can call
 >
 >      (set-window-start win ws nil 'group)
 >
 > and this will do the Right Thing regardless of whether Follow Mode (or
 > whatever) is active or not.  GROUP non-nil just says "work on the whole
 > group of windows if there is one".

So the idea is that ‘follow-mode’ sets `set-window-start-group-function'
to say ‘follow-mode-set-window-start’ which is then called whenever
‘isearch-mode’ calls ‘set-window-start’.  Since you don't do this on a
per window basis, ‘follow-mode-set-window-start' can be also called for
windows that are not managed by ‘follow-mode’ probably in the hope that
‘follow-mode-set-window-start’ temporarily binds
‘set-window-start-group-function’ to nil around a nested call to
‘set-window-start’.  It strikes me as a bad idea that
‘follow-mode-set-window-start’ has to take care of windows that are not
in ‘follow-mode’.

And you preclude the simultaneous use of a second mode operating on a
disjoint group of windows maybe even on another frame - there's only one
global ‘set-window-start-group-function’ variable.  Your approach
doesn't scale.

 >> An argument with such a name should be non-nil only in calls by
 >> ‘follow-mode’ or other packages that know that WINDOW is part of some
 >> "group".
 >
 > Absolutely the reverse.  See above.  Actually, most calls from Follow
 > Mode, which will be about rearranging the individual windows, will be
 > called with GROUP set to nil.

Obviously so.  I consider this a drawback.

 >> ‘isearch-mode’ has no idea whether WINDOW is part of a group and should
 >> not have to.
 >
 > By my proposal, it wouldn't have to.  But it would have to be aware of
 > the possibility.

By my proposal it wouldn't even have to be aware of the possibility.

 >> OTOH somebody might want ‘set-window-start’ to behave specially even
 >> when WINDOW is not part of a group.
 >
 > This sounds a bit hypothetical.  Do you have an example of the sort of
 > thing this might be?

I can easily devise one: Suppose I want text-mode windows to always
start at the beginning of a paragraph and prog-mode windows at the
beginning of a defun provided it is within easy reach, say at most three
lines, from the position proposed by ‘set-window-start’.  Do we really
want to tell people that in such case they should use an argument called
"GROUPS"?

 > I think what you mean is that `set-window-start' would first test the
 > window-parameter, and if that is a function, would call the function
 > instead of doing set-window-start's normal stuff.

Just as in `delete-window', yes.

 > The problem I see with that is that when some code wants to set the
 > window start of an individual window, it's going to have to do something
 > like this:
 >
 >      (let ((save-ws-param (window-parameter win 'set-window-start)))
 >        (set-window-parameter win 'window-start nil)
 >        (set-window-start win ws)
 >        (set-window-parameter win 'window-start save-ws-param))
 >
 > , which is rather clumsy.  In fact, the situation almost calls for a
 > macro which would look something like:
 >
 >      (with-window-parameters-set win '((set-window-start . nil))
 >        (set-window-start win ws))
 >
 > , but even this isn't very pretty.

It would do

(let ((ignore-window-parameters t))
   (set-window-start win ws))

 >>   > The second attempt, a week or two ago, invented new functions with new
 >>   > names to perform the functions of `window-start' etc., on either a
 >>   > group of windows or a single window.  Eli criticised this, saying:
 >
 >>   >> Btw, I see no reason to introduce new functions.  Instead, we could
 >>   >> have the original ones accept an additional optional argument.
 >
 >> Above I explained why IMO the new argument is not about "groups".
 >
 > I still think it is.

I still think it is not.

 > But the criterion as to whether a `set-window-start' call wants to
 > operate on an individual window or the group (if there is one) would be
 > attached to the window rather than to the call.  I don't think this is
 > right.

Above I tried to explain why attaching the criterion to a call is
insufficient.

 > They cannot be.  They are packages which do their own window
 > manipulation, and so will have to make up their minds whether a
 > particular `window-start' or `pos-visiblie-in-window-p' refers to an
 > individual window or to the group (if any).  This distinction is
 > essentially encapsulated in the package.

Which package?

 > It is more convenient for a
 > package to set an optional parameter to nil or non-nil than to have to
 > "bind" a window parameter to nil.

I suppose the package you care about is ‘follow-mode’.  As far as
isearch and all other packages are concerned, it's obviously easier to
neither set a window parameter nor an optional argument.

 > Distorting your meaning for a paragraph: Under my proposal, there is no
 > urgent need to update any package which uses `set-window-start' and
 > friends.  If it currently fails to work well with FM, it will continue to
 > work just the same until somebody amends it.  Your proposal is more
 > radical: we'd have to check each of the 124 uses of
 > `pos-visible-in-window-p' to make sure they actually should work on
 > entire window groups.  I would guess most of them will, but some won't.
 > It would, of course, also affect external code.

‘follow-mode-set-window-start’ would have to take care of that.  If you
really care about this have ‘follow-mode-set-window-start’ check a
variable like ‘isearch-mode’ to make sure that it affects isearch calls
only.

 >>   > Also, were Follow Mode to be superseded at any time, then the interface
 >>   > I'm proposing would not need adapting to FM's successor.
 >
 >> The interface you propose already needs adapting up to 132 libraries to
 >> FM.
 >
 > No.  There is no need, see above, even though it would be beneficial.
 > With your proposal, we'd need to check a lot of code.

If we changed up to 132 arguments in calls of ‘set-window-start’ and
decided that ‘follow-mode’ is obsolete we'd have up to 132 calls to
change back.

martin

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

[Alan Mackenzie]

Hello, Martin.

On Sun, Nov 08, 2015 at 07:10:51PM +0100, martin rudalics wrote:
>  > Well, it's now been renamed `set-window-start-group-function', but
>  > basically, yes.  The caller would call `set-window-start' without having
>  > to know whether FM is active or not.

>  >> If so, then how comes that this argument is called "GROUP"?

>  > The idea is that a general package, like isearch, can call

>  >      (set-window-start win ws nil 'group)

>  > and this will do the Right Thing regardless of whether Follow Mode (or
>  > whatever) is active or not.  GROUP non-nil just says "work on the whole
>  > group of windows if there is one".

> So the idea is that ‘follow-mode’ sets `set-window-start-group-function'
> to say ‘follow-mode-set-window-start’ which is then called whenever
> ‘isearch-mode’ calls ‘set-window-start’.  Since you don't do this on a
> per window basis, ‘follow-mode-set-window-start' can be also called for
> windows that are not managed by ‘follow-mode’ ....

No.  `set-window-start-group-function' is buffer local.  The state of
being managed by Follow Mode is also a buffer local thing - in any given
Emacs session, either all windows displaying foo.el or none of them have
Follow Mode active.  If they are in different frames, FM manages them as
disjoint groups.

> .... probably in the hope that ‘follow-mode-set-window-start’
> temporarily binds ‘set-window-start-group-function’ to nil around a
> nested call to ‘set-window-start’.

The recursive call to `set-window-start' has its GROUP parameter nil.
There is no need for such temporary binding.

> It strikes me as a bad idea that ‘follow-mode-set-window-start’ has to
> take care of windows that are not in ‘follow-mode’.

It doesn't, because of the buffer localness of `s-w-s-g-f', combined with
the all-or-nothingness of Follow Mode on a buffer.

> And you preclude the simultaneous use of a second mode operating on a
> disjoint group of windows maybe even on another frame - there's only one
> global ‘set-window-start-group-function’ variable.  Your approach
> doesn't scale.

If the disjoint group is displaying a different buffer, there is no
problem, the xx-group-function's all being buffer local.  If it's the
same buffer - well, it sounds like rather a hypothetical case to me.  It
would involve the set-window-start-group-function having to chose which
of the two schemes it would use, depending on some flag, frame parameter,
or what have you.  Nothing would be precluded.

>  >> An argument with such a name should be non-nil only in calls by
>  >> ‘follow-mode’ or other packages that know that WINDOW is part of some
>  >> "group".

>  > Absolutely the reverse.  See above.  Actually, most calls from Follow
>  > Mode, which will be about rearranging the individual windows, will be
>  > called with GROUP set to nil.

> Obviously so.  I consider this a drawback.

If things were to be implemented with a window parameters as you suggest,
this would add a lot to the complexity of Follow Mode, since each call to
one of the window primitives would have to be surrounded by code
nullifying a window parameter.  Adding GROUP optional arguments is, by
comparison, trivial and non-intrusive.  I've done it.

>  >> ‘isearch-mode’ has no idea whether WINDOW is part of a group and should
>  >> not have to.

>  > By my proposal, it wouldn't have to.  But it would have to be aware of
>  > the possibility.

> By my proposal it wouldn't even have to be aware of the possibility.

It would have to be.  For a hypothetical example, say there's some minor
mode which keeps something or other in a buffer at least n lines away
from a window boundary.  Its maintainer would need to decide whether that
just means n lines from the top/bottom of the entire FM group, or from
the "internal" boundaries too.

>  >> OTOH somebody might want ‘set-window-start’ to behave specially even
>  >> when WINDOW is not part of a group.

>  > This sounds a bit hypothetical.  Do you have an example of the sort of
>  > thing this might be?

> I can easily devise one: Suppose I want text-mode windows to always
> start at the beginning of a paragraph and prog-mode windows at the
> beginning of a defun provided it is within easy reach, say at most three
> lines, from the position proposed by ‘set-window-start’.  Do we really
> want to tell people that in such case they should use an argument called
> "GROUPS"?

How would you program that now, without the GROUP facility?  That's how
you'd still do it with GROUP in existence.  To use the
xx-group-function's for this sort of thing would be an abuse of them.

[ .... ]

>  > The problem I see with that is that when some code wants to set the
>  > window start of an individual window, it's going to have to do something
>  > like this:

>  >      (let ((save-ws-param (window-parameter win 'set-window-start)))
>  >        (set-window-parameter win 'window-start nil)
>  >        (set-window-start win ws)
>  >        (set-window-parameter win 'window-start save-ws-param))

>  > , which is rather clumsy.  In fact, the situation almost calls for a
>  > macro which would look something like:

>  >      (with-window-parameters-set win '((set-window-start . nil))
>  >        (set-window-start win ws))

>  > , but even this isn't very pretty.

> It would do

> (let ((ignore-window-parameters t))
>    (set-window-start win ws))

That's assuming that _all_ window parameters have to be ignored at once.
But even that pair of lines is over twice as bulky as simply writing

    (set-windows-start win ws)

.

I see a further problem with the window parameters approach.  When a
different buffer becomes displayed in such a window, the parameter would
stay set.  There is a fundamental mismatch here: Follow Modishness is
associated with a buffer (not a set of windows); window parameters are
fundamentally attached to windows.  This clash is bound to cause
awkwardnesses.  So, to cope with temporary buffer changes, one would have
to build whole complexes of mechanisms to temporarily delete the window
parameters, and so on.

[ .... ]

>  > But the criterion as to whether a `set-window-start' call wants to
>  > operate on an individual window or the group (if there is one) would be
>  > attached to the window rather than to the call.  I don't think this is
>  > right.

> Above I tried to explain why attaching the criterion to a call is
> insufficient.

It may or may not be sufficient, but it is necessary.  I'm trying to
imagine things if `set-window-start''s NOFORCE argument had instead been
implemented as a window parameter.  It would make programming windows
that bit more clumsy than it is at the moment.  I can't see at all where
the GROUP argument is any different.

>  > They cannot be.  They are packages which do their own window
>  > manipulation, and so will have to make up their minds whether a
>  > particular `window-start' or `pos-visiblie-in-window-p' refers to an
>  > individual window or to the group (if any).  This distinction is
>  > essentially encapsulated in the package.

> Which package?

Edebug, for example.  It gathers things like `window-start's, so that it
can rebuild a window layout when switching between modes.  Or something.
Here, these calls clearly call for GROUP to be nil.  If the window
parameter approach were chosen, edebug.el would need modifying.  As
would, potentially, lots of other packages.

>  > It is more convenient for a
>  > package to set an optional parameter to nil or non-nil than to have to
>  > "bind" a window parameter to nil.

> I suppose the package you care about is ‘follow-mode’.  As far as
> isearch and all other packages are concerned, it's obviously easier to
> neither set a window parameter nor an optional argument.

Yes, I care about Follow Mode.  And I care about Isearch, a great deal.
The two currently don't work together.  Something like an optional
argument or a window parameter is absolutely needed to make them work
together.

>  > Distorting your meaning for a paragraph: Under my proposal, there is no
>  > urgent need to update any package which uses `set-window-start' and
>  > friends.  If it currently fails to work well with FM, it will continue to
>  > work just the same until somebody amends it.  Your proposal is more
>  > radical: we'd have to check each of the 124 uses of
>  > `pos-visible-in-window-p' to make sure they actually should work on
>  > entire window groups.  I would guess most of them will, but some won't.
>  > It would, of course, also affect external code.

> ‘follow-mode-set-window-start’ would have to take care of that.

It can't do, any more than `set-window-start' could take care of an
implicit NOFORCE parameter.

> If you really care about this have ‘follow-mode-set-window-start’ check
> a variable like ‘isearch-mode’ to make sure that it affects isearch
> calls only.

I take it that's a bit of sarcasm?

>  >>   > Also, were Follow Mode to be superseded at any time, then the interface
>  >>   > I'm proposing would not need adapting to FM's successor.

>  >> The interface you propose already needs adapting up to 132 libraries to
>  >> FM.

>  > No.  There is no need, see above, even though it would be beneficial.
>  > With your proposal, we'd need to check a lot of code.

> If we changed up to 132 arguments in calls of ‘set-window-start’ and
> decided that ‘follow-mode’ is obsolete we'd have up to 132 calls to
> change back.

Not at all.  The interface would remain unchanged, only the setting of
`set-window-start-group-function' would need to change.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Juri Linkov]

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

It shouldn't be slow with a sufficiently low value of lazy-highlight-max-at-a-time.

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

Yes, I remember, and appreciate your efforts to develop it further.

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

I tried to not use isearch-string-out-of-window/isearch-back-into-window
at all, but I can't get a useful behavior in such situation of scrolling
out of the window with the current search hit.  Could you show how you see
it should work in this case in follow-mode?

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

I meant such things as 'M-: (message "x\ny\nz") RET' causes jumping too.

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

The problem is that you are trying to design a new framework,
but not demonstrated yet how it would be useful generally in cases
other than a specific combination of isearch/follow-mode.

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

[martin rudalics]

 > I see a further problem with the window parameters approach.  When a
 > different buffer becomes displayed in such a window, the parameter would
 > stay set.  There is a fundamental mismatch here: Follow Modishness is
 > associated with a buffer (not a set of windows); window parameters are
 > fundamentally attached to windows.  This clash is bound to cause
 > awkwardnesses.

One of the worst things I've ever seen in the windows code was the
mixing in of buffer-local variables, the most notorious representative
of them being ‘window-size-fixed’.  I meanwhile found a workaround so it
shouldn't be needed any more.  Still that variable is a pain.

 > So, to cope with temporary buffer changes, one would have
 > to build whole complexes of mechanisms to temporarily delete the window
 > parameters, and so on.

All this would be restricted to Follow Mode without affecting anyone
else.

 >> If you really care about this have ‘follow-mode-set-window-start’ check
 >> a variable like ‘isearch-mode’ to make sure that it affects isearch
 >> calls only.
 >
 > I take it that's a bit of sarcasm?

Sorry.  It wasn't meant that way.

I think I have bothered you long enough with my objections.  I consider
it most unfortunate that your previous solutions were not accepted.  I
could have easily lived with all of them.  But I neither use isearch nor
follow mode so I'm probably not in a good position to judge.  The
current solution introduces a new approach which IMHO doesn't fit with
the rest of the windows code but let's live with it.

So thanks for putting so much care into your responses and good luck (no
sarcasm) with the current scheme.

martin

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

[Alan Mackenzie]

Hello, Juri.

On Mon, Nov 09, 2015 at 02:50:04AM +0200, Juri Linkov wrote:
> >> 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?

> It shouldn't be slow with a sufficiently low value of lazy-highlight-max-at-a-time.

OK, I see it: it would be slow if it had to go to completion, but any
key/mouse/other event will terminate it.  So the only place it might be a
problem is somewhere where CPU cycles are at a premium.

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

> I tried to not use isearch-string-out-of-window/isearch-back-into-window
> at all, but I can't get a useful behavior in such situation of scrolling
> out of the window with the current search hit.  Could you show how you see
> it should work in this case in follow-mode?

To start with, set

  (global-set-key [next] 'follow-scroll-up)
  (global-set-key [prior] 'follow-scroll-down)
  (setq isearch-allow-scroll t)

.  Then start an Isearch not too close to the start of a buffer with
Follow Mode enabled with at least two windows.  Type something to get a
search match highlighted.  Now <PageUp> and <PageDown> should scroll that
match between Follow Mode windows, the boundaries of that scrolling being
the top of the LH window and the bottom of the RH window.

To make this work properly, the four variables in
isearch-string-out-of-window, w-start, w-end, w-L1, w-L-1, are set to the
positions in the entire group of windows, by setting the proposed
&optional argument GROUP to t in the calls to certain window functions,
e.g.

     (let ((w-start (window-start nil t))
                                      ^

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

> I meant such things as 'M-: (message "x\ny\nz") RET' causes jumping too.

It causes some scrolling of windows to keep them properly aligned when
the echo area expands to three lines.  This is expected and proper.
However, when the echo area goes back to one line, the windows don't
scroll back again, leaving them unaligned.  I raised a bug for this this
morning.  It seems it is a known problem which is tricky to solve.

> >> 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, where do we go from here?  I would like these bugs fixed for 25.1.

> The problem is that you are trying to design a new framework,
> but not demonstrated yet how it would be useful generally in cases
> other than a specific combination of isearch/follow-mode.

Any elisp software which manipulates windows will be able to work better
by considering entire FM groups.  I did some grepping: here are some
examples which the new framework could improve:

`kill-ring-save' should blink the cursor on the matching other-end, if
that is visible.  With FM active, and other end being in a different
window, currently it wrongly outputs a message instead.

`window-screen-lines' could be enhanced (optionally) to return the number
of screen lines in the entire group.

`blink-matching-open' could be enhanced to handle FM windows properly.

`ns-scroll-bar-move' (probably) should `set-window-start' for the entire
window group.  This (might) avoid scrolling such that the RH follow
window is displaying empty space.


One point about this new framework is that it is "harmless" in the sense
that anything which worked (or failed to work) prior to it will continue
unchanged unless specifically amended.  It's disadvantage is that it adds
a little to the bulk of things people need to know or to look up in
manuals.

I think Follow Mode should become easier to use, both for users and for
hackers, especially given that wide screens (>200 characters) are now the
norm rather than the exception.  At the moment Follow Mode is
ridiculously difficult to start (manually splitting windows, doing M-x
follow-mode) and even more difficult to hack for - just what interfaces
are currently available for making a package work with FM?  Answer: none
at all.  This new framework is intended to go some way to closing the
gap.

The alternative to a framework is a bugfix which is specific to Isearch.
Even this would require some sort of interface definition and
abstraction.  At a minimum, for "part 3" of the bug, Isearch would need
somehow to obtain the bounds of the group of windows.

The last alternative is a quick and dirty fix where Isearch would just
call Follow Mode functions.  I don't think anybody really wants this.

Would it help if I actually made the source available?  If so, where?  I
don't really think it would be appropriate to dump a patch of this size
on emacs-devel, and the time to commit the changes to master has clearly
not yet arrived.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Martin.

On Mon, Nov 09, 2015 at 09:25:52AM +0100, martin rudalics wrote:
>  > I see a further problem with the window parameters approach.  When a
>  > different buffer becomes displayed in such a window, the parameter would
>  > stay set.  There is a fundamental mismatch here: Follow Modishness is
>  > associated with a buffer (not a set of windows); window parameters are
>  > fundamentally attached to windows.  This clash is bound to cause
>  > awkwardnesses.

> One of the worst things I've ever seen in the windows code was the
> mixing in of buffer-local variables, the most notorious representative
> of them being ‘window-size-fixed’.  I meanwhile found a workaround so it
> shouldn't be needed any more.  Still that variable is a pain.

Presumably a lot of the pain came from the fact that that variable is
attached to a buffer, rather than a window (as it should have been).

> I think I have bothered you long enough with my objections.  I consider
> it most unfortunate that your previous solutions were not accepted.  I
> could have easily lived with all of them.  But I neither use isearch nor
> follow mode so I'm probably not in a good position to judge.  The
> current solution introduces a new approach which IMHO doesn't fit with
> the rest of the windows code but let's live with it.

> So thanks for putting so much care into your responses and good luck (no
> sarcasm) with the current scheme.

Thank you for jousting with me!  I learnt something (the existence of
window parameters).

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

> This suggestion doesn't seem to have sparked off too much debate. Can I take
> it that people are generally happy about it? In that case, I will commit the
> change.

Hi Alan,

First, I want to say that I'm very sorry this change has generated so much
effort for you. This is highly suboptimal, since you could have spent that
time doing other things for Emacs.

Second, I don't know that your change is ready for master today, but I *am*
ready to exempt it from the feature freeze. So please keep it on a branch for
now, and we will continue the discussion. If we can reach a satisfying
implementation, it will be in 25.1.

Would you be willing, one last time, to summarize the impact (from a
documentation perspective) of this change for Emacs users and for Emacs Lisp
developers? I think the *content* of the change is without reproach -- making
Follow Mode more valuable -- it is simply the form of the change that we need
more consensus on.

Adding your proposal to the Emacs Wiki Proposals page
(http://www.emacswiki.org/emacs/Proposals) would be a good way to liberate the
current state of your work from this lengthy discussion, so I can look at it
again with fresh eyes.

With gratitude for your perseverance,
  John

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

[Alan Mackenzie]

Hello, John.

On Mon, Nov 09, 2015 at 02:30:09PM -0800, John Wiegley wrote:
> >>>>> Alan Mackenzie <acm@muc.de> writes:

> > This suggestion doesn't seem to have sparked off too much debate. Can I take
> > it that people are generally happy about it? In that case, I will commit the
> > change.

> Hi Alan,

> First, I want to say that I'm very sorry this change has generated so much
> effort for you. This is highly suboptimal, since you could have spent that
> time doing other things for Emacs.

Thanks.  I think that the way I've presented this change has been less
than optimal in some way.  If I were on the other side, I think I might
be as wary/concerned/sceptical about the change as other people
currently are.  I've had some tips on this aspect from Juri.  I'll see
if I can follow them a bit better in the future.

> Second, I don't know that your change is ready for master today, but I *am*
> ready to exempt it from the feature freeze. So please keep it on a branch for
> now, and we will continue the discussion. If we can reach a satisfying
> implementation, it will be in 25.1.

The change works.  I have also amended several elisp manual pages,
though these doc changes could use a review from other people.
Technically, I believe the change is ready.

> Would you be willing, one last time, to summarize the impact (from a
> documentation perspective) of this change for Emacs users and for Emacs Lisp
> developers? I think the *content* of the change is without reproach -- making
> Follow Mode more valuable -- it is simply the form of the change that we need
> more consensus on.

Oh, OK.  ;-)

> Adding your proposal to the Emacs Wiki Proposals page
> (http://www.emacswiki.org/emacs/Proposals) would be a good way to liberate the
> current state of your work from this lengthy discussion, so I can look at it
> again with fresh eyes.

> With gratitude for your perseverance,
>   John

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello again, John.

On Mon, Nov 09, 2015 at 02:30:09PM -0800, John Wiegley wrote:
> >>>>> Alan Mackenzie <acm@muc.de> writes:

> Would you be willing, one last time, to summarize the impact (from a
> documentation perspective) of this change for Emacs users and for Emacs Lisp
> developers? I think the *content* of the change is without reproach -- making
> Follow Mode more valuable -- it is simply the form of the change that we need
> more consensus on.

> Adding your proposal to the Emacs Wiki Proposals page
> (http://www.emacswiki.org/emacs/Proposals) would be a good way to liberate the
> current state of your work from this lengthy discussion, so I can look at it
> again with fresh eyes.

Done.

> With gratitude for your perseverance,
>   John

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

>> Adding your proposal to the Emacs Wiki Proposals page
>> (http://www.emacswiki.org/emacs/Proposals) would be a good way to liberate the
>> current state of your work from this lengthy discussion, so I can look at it
>> again with fresh eyes.

> Done.

You are my hero today. :)

I will go through it and respond back, hopefully before day's end.

John

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

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

>> Adding your proposal to the Emacs Wiki Proposals page
>> (http://www.emacswiki.org/emacs/Proposals) would be a good way to liberate the
>> current state of your work from this lengthy discussion, so I can look at it
>> again with fresh eyes.

> Done.

Great proposal. I have an idea about this functionality I'd like to suggest.

Right now we have a set of functions with well-defined behavior. Under certain
conditions of use, those functions are too specific. You'd like to change the
functions' API so that some packages (follow-mode) can change what they mean,
and requiring other packages (isearch) to explicitly allow the override.

Maybe the problem is that we've turned object-orientation inside out. What we
really care about is not the set of functions, but the notion of what "current
window" means. It needs to be broader in scope when follow-mode is active, to
address the notion that multiple windows are being knit together, visually. It
has nothing to do with isearch, so ideally the change shouldn't affect it.

What if we just had `window-start-function', receiving the window as its
argument -- effectively having getter and setters on window objects. Could
follow-mode determine from the argument whether the window was involved in its
"group", and act accordingly? That would avoid API changes, is cheaper to do,
and no modes would have to change.

That is:

          window-start WIND
    calls (funcall window-start-function WIND)
    calls window-object-start WIND

So the current window-start is renamed to window-object-start (or some
internal sounding name), which is reached by indirecting through the variable
window-start-function.

I wonder, though, if such extensibility is worth the extra layer of
indirection. It feels a bit... special-cased and not very elegant, maybe? Do
we care enough about follow-mode to make a core change like this?

It could also be that we're looking too much at a specific solution, by
needing window-start to change its meaning in order to support correct
behavior by isearch. Is there a screencast anywhere, so I could see what
follow-mode with isearch looks like using your patch, and what it looks like
without the patch? Is anyone else using this code?

John

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

[Alan Mackenzie]

Hello, John.

It's getting late, but seeing as how we're nine hours' timezones apart,
I'd like to get this out tonight.

On Tue, Nov 10, 2015 at 02:29:18PM -0800, John Wiegley wrote:
> >>>>> Alan Mackenzie <acm@muc.de> writes:

> >> Adding your proposal to the Emacs Wiki Proposals page
> >> (http://www.emacswiki.org/emacs/Proposals) would be a good way to liberate the
> >> current state of your work from this lengthy discussion, so I can look at it
> >> again with fresh eyes.

> > Done.

> Great proposal. I have an idea about this functionality I'd like to suggest.

> Right now we have a set of functions with well-defined behavior. Under certain
> conditions of use, those functions are too specific. You'd like to change the
> functions' API so that some packages (follow-mode) can change what they mean,
> and requiring other packages (isearch) to explicitly allow the override.

> Maybe the problem is that we've turned object-orientation inside out. What we
> really care about is not the set of functions, but the notion of what "current
> window" means. It needs to be broader in scope when follow-mode is active, to
> address the notion that multiple windows are being knit together, visually. It
> has nothing to do with isearch, so ideally the change shouldn't affect it.

If only we lived in an ideal world.  ;-)

> What if we just had `window-start-function', receiving the window as its
> argument -- effectively having getter and setters on window objects. Could
> follow-mode determine from the argument whether the window was involved in its
> "group", and act accordingly? That would avoid API changes, is cheaper to do,
> and no modes would have to change.

Follow Mode could indeed determine this.  However, expecting everything
else just to work is being too optimistic.  The display engine and Follow
Mode fight each other, to some extent.  Follow Mode, for example,
continually monitors where point it, and thus which window it is
logically in.  It then puts point physically into that window, preventing
the display engine from messing everything up.  For example.

If things aren't done very carefully, display artefacts ruin the effect.
I had to diagnose and correct one of these in Isearch.  The cause was
point being in the wrong place at the wrong time.

Also, Follow Mode would need access to the raw `window-start', etc.,
since it has to manipulate each window individually, so this would
need some extension of the existing interface anyway.

> That is:

>           window-start WIND
>     calls (funcall window-start-function WIND)
>     calls window-object-start WIND

> So the current window-start is renamed to window-object-start (or some
> internal sounding name), which is reached by indirecting through the variable
> window-start-function.

> I wonder, though, if such extensibility is worth the extra layer of
> indirection. It feels a bit... special-cased and not very elegant, maybe? Do
> we care enough about follow-mode to make a core change like this?

Things like window-start are C primitives, and called a lot from other C
code.  They really have to stay basically as they are.

The abstraction created by Follow Mode is really rather fragile.  I do
not feel that trying to make such an automatic "object-like" solution
would be a good idea, though I haven't thought it through thoroughly,
yet.  (A lovely bit of linguistic contrast, no?)

Still, you've been giving me ideas.  The ideal place to implement Follow
Mode would be inside the display engine, mainly in C.  Then we could
truly treat a "multiple" window as a single object.  Such a "multiple"
window could, for example, have a single (vertical) scroll bar and
possibly a single mode line.  Although it wouldn't be all that easy to
implement, it probably wouldn't be as difficult as all that.  I'm
guessing it would take longer than Friday 13th November to finish,
though.

> It could also be that we're looking too much at a specific solution, by
> needing window-start to change its meaning in order to support correct
> behavior by isearch. Is there a screencast anywhere, so I could see what
> follow-mode with isearch looks like using your patch, and what it looks like
> without the patch? Is anyone else using this code?

No, but a screen shot wouldn't really be helpful.  It's behaviour rather
than appearance that matters here.  A video would be the best thing, if I
had the technology to make one.  Maybe the best thing would be for me to
make the patch available in some fashion so that you can try it out.  The
total size of the two patches is currently ~1700 lines (About 350 lines
for Isearch, and 1350 lines for the framework, including documentation
changes).  As yet, nobody else is using it.  The patch has not yet left
my PC (apart from backup copies).

> John

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

> Still, you've been giving me ideas. The ideal place to implement Follow Mode
> would be inside the display engine, mainly in C. Then we could truly treat a
> "multiple" window as a single object. Such a "multiple" window could, for
> example, have a single (vertical) scroll bar and possibly a single mode
> line. Although it wouldn't be all that easy to implement, it probably
> wouldn't be as difficult as all that. I'm guessing it would take longer than
> Friday 13th November to finish, though.

These are some intriguing thoughts. The 25.1 release cycle may last a while,
so this could still land in a few weeks (beyond the freeze), out of respect
for your efforts to do this right. If it gets too late, though, it would be
better in 25.2 (which I'm hoping will follow just a few months later).

> No, but a screen shot wouldn't really be helpful. It's behaviour rather than
> appearance that matters here. A video would be the best thing, if I had the
> technology to make one. Maybe the best thing would be for me to make the
> patch available in some fashion so that you can try it out. The total size
> of the two patches is currently ~1700 lines (About 350 lines for Isearch,
> and 1350 lines for the framework, including documentation changes). As yet,
> nobody else is using it. The patch has not yet left my PC (apart from backup
> copies).

Would you be available via Firefox Hello some evening, so that you could share
you screen and give me a demo? I'd like to get a better feel for this than my
imagination. I'm available right now in fact. :)

John

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

[Alan Mackenzie]

Hello, John.

On Tue, Nov 10, 2015 at 04:34:13PM -0800, John Wiegley wrote:
> >>>>> Alan Mackenzie <acm@muc.de> writes:

> > Still, you've been giving me ideas. The ideal place to implement Follow Mode
> > would be inside the display engine, mainly in C. Then we could truly treat a
> > "multiple" window as a single object. Such a "multiple" window could, for
> > example, have a single (vertical) scroll bar and possibly a single mode
> > line. Although it wouldn't be all that easy to implement, it probably
> > wouldn't be as difficult as all that. I'm guessing it would take longer than
> > Friday 13th November to finish, though.

> These are some intriguing thoughts. The 25.1 release cycle may last a while,
> so this could still land in a few weeks (beyond the freeze), out of respect
> for your efforts to do this right. If it gets too late, though, it would be
> better in 25.2 (which I'm hoping will follow just a few months later).

Adapting the display engine to handle Follow Mode type functionality is
something that, perhaps, Eli could implement in a few days.  It would
take me many weeks, at best.  Even specifying precisely what it would
have to do is far from trivial.

> > No, but a screen shot wouldn't really be helpful. It's behaviour rather than
> > appearance that matters here. A video would be the best thing, if I had the
> > technology to make one. Maybe the best thing would be for me to make the
> > patch available in some fashion so that you can try it out. The total size
> > of the two patches is currently ~1700 lines (About 350 lines for Isearch,
> > and 1350 lines for the framework, including documentation changes). As yet,
> > nobody else is using it. The patch has not yet left my PC (apart from backup
> > copies).

> Would you be available via Firefox Hello some evening, so that you could share
> you screen and give me a demo? I'd like to get a better feel for this than my
> imagination. I'm available right now in fact. :)

I don't seem to have Hello in my Firefox, though I've got version 38.4.
Perhaps the folk at Gentoo stripped it out for some reasone, or I built
it with some "use flag" (sorry for the Gentoo jargon) not set.  Or
something.

I have finally uploaded the source to savannah, in branch
scratch/follow (assuming git hasn't fooled me about this).  Why don't
you try it out yourself?

Successively, in standard master and the scratch/follow branch, do this:
1. emacs -Q

2. (global-set-key [next] 'follow-scroll-up)
   (global-set-key [prior] 'follow-scroll-down)
   (setq isearch-allow-scroll t)

3. C-x C-f path/to/src/xdisp.c

4. C-x 3,  C-x 3,  C-x +,  M-x follow-mode  (if necessary, use the mouse
to make the frame wide).

5. C-s t e x t.  Pause between the letters, and note the lazy
highlighting.  It should extend over all 3 windows.  Play around with
various search texts.

6. (Still in C-s t e x t).  Repeatedly do C-s.  Point should move onto
the middle window, then the RH window, then (and only then) the whole
collection should scroll.

7. (Not in C-s): Move point some distance away from the beginning of
buffer.  Start a C-s, and manipulate things such that the current match
is in the middle window.  <PageUp> and <PageDown> should scroll the
current match BETWEEN WINDOWS.

8. Start a C-s near the bottom of the LH window.  Continually do M-s
C-e, until the highlighted search area is split between LH and middle
windows.  Everything should display properly at this point.  Continue
doing M-s C-e, until the echo area expands by one line.  Everything
should continue to display properly.

#########################################################################

9. (Inside the xdisp.c code area): Find a pair of braces not too far
apart, on the same window.  Delete the closing brace, then retype it.
Note how the cursor jumps to the matching opening brace.  Now scroll the
text such that the two braces are on neighbouring windows.  When you do
the same, instead of the momentary jump to the opening brace, you get a
message instead.

This is a bug, if a small one.  It is the sort of thing that can be
corrected trivially by the new framework; adding a 't' argument to the
invocation of a primitive is all it would take.


> John

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

> Even specifying precisely what it would have to do is far from trivial.

It will still be very good to have a specification. If we try to support a
feature we can't properly define.. much hard.

> I don't seem to have Hello in my Firefox, though I've got version 38.4.
> Perhaps the folk at Gentoo stripped it out for some reasone, or I built it
> with some "use flag" (sorry for the Gentoo jargon) not set. Or something.

If you have anything else available, I use many means for conferencing.

> I have finally uploaded the source to savannah, in branch
> scratch/follow (assuming git hasn't fooled me about this).  Why don't
> you try it out yourself?

I would love to, but at the moment I'm having difficulties just building
master. If you could show me, then you won't be stuck on me.

John

Comms and building Emacs. [Re: Framework extending window functions for Follow Mode (etc.).]

[Alan Mackenzie]

Hello, John.

On Wed, Nov 11, 2015 at 08:50:41AM -0800, John Wiegley wrote:
> >>>>> Alan Mackenzie <acm@muc.de> writes:

> > Even specifying precisely what it would have to do is far from trivial.

> It will still be very good to have a specification. If we try to support a
> feature we can't properly define.. much hard.

It would be essential to have such a spec, even if we ended up having to
change the spec as we went along.

> > I don't seem to have Hello in my Firefox, though I've got version 38.4.
> > Perhaps the folk at Gentoo stripped it out for some reasone, or I built it
> > with some "use flag" (sorry for the Gentoo jargon) not set. Or something.

> If you have anything else available, I use many means for conferencing.

I've never done anything like that before.  Sorry if it has appeared
that I was just being awkward.  I do have a (probably working)
earphones/microphone combination, though.  I think I'll ask on the
Gentoo list if anybody knows what might have happened to my Firefox
Hello.

> > I have finally uploaded the source to savannah, in branch
> > scratch/follow (assuming git hasn't fooled me about this).  Why don't
> > you try it out yourself?

> I would love to, but at the moment I'm having difficulties just building
> master. If you could show me, then you won't be stuck on me.

Is the emphasis on "at the moment" or on the "I'm having difficulties"?
If the former, hopefully the person who committed the build-breaking
commit will fix it.

If you've been so preoccupied by the duties of maintainer that you
haven't yet got a build to succeed, here are some tips:

1. The process is described in INSTALL.REPO in our top level directory.
2. This process is basically:
  (i) From the top level directory ...
  (ii)  ./autogen.sh
  (iii) ./configure    # You can put options here, such as for
                       # debugging, or a host of other things.
  (iv) make -j5 bootstrap # This step is critical the first time you
                          # build a repository.  The "-j5" is for the
			  # number of make jobs you have running at a
			  # time.  Recommended: # of cores + 1.
  (v) make -j5            # For the second and subsequent times you
                          # build.
3. The executable "emacs", hard-linked to "emacs-25.0.50.n", ends up in
the src directory.  To run it, just type "src/emacs -Q" (or whatever).


> John

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Comms and building Emacs. [Re: Framework extending window functions for Follow Mode (etc.).]

[Alan Mackenzie]

Hello, John.

On Wed, Nov 11, 2015 at 05:15:48PM +0000, Alan Mackenzie wrote:

[ .... ]

> 1. The process is described in INSTALL.REPO in our top level directory.
> 2. This process is basically:
>   (i) From the top level directory ...
>   (ii)  ./autogen.sh
>   (iii) ./configure    # You can put options here, such as for
>                        # debugging, or a host of other things.
>   (iv) make -j5 bootstrap # This step is critical the first time you
>                           # build a repository.  The "-j5" is for the
> 			  # number of make jobs you have running at a
> 			  # time.  Recommended: # of cores + 1.

Correction:  The make bootstrap is not needed on a new repository.  I've
just tried it.  Apologies.

>   (v) make -j5            # For the second and subsequent times you
>                           # build.
> 3. The executable "emacs", hard-linked to "emacs-25.0.50.n", ends up in
> the src directory.  To run it, just type "src/emacs -Q" (or whatever).


> > John

-- 
Alan Mackenzie (Nuremberg, Germany).