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

[Alan Mackenzie <acm@muc.de>]

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