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