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