[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Framework extending window functions for Follow Mode (etc.).
From: |
martin rudalics |
Subject: |
Re: Framework extending window functions for Follow Mode (etc.). |
Date: |
Sun, 08 Nov 2015 10:22:44 +0100 |
> 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.)., (continued)
Re: Framework extending window functions for Follow Mode (etc.)., martin rudalics, 2015/11/07
- Re: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/07
- Re: Framework extending window functions for Follow Mode (etc.)., martin rudalics, 2015/11/07
- Re: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/07
- Re: Framework extending window functions for Follow Mode (etc.)., martin rudalics, 2015/11/07
- Re: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/07
- Re: Framework extending window functions for Follow Mode (etc.).,
martin rudalics <=
- Re: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/08
- Re: Framework extending window functions for Follow Mode (etc.)., martin rudalics, 2015/11/08
- Re: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/08
- Re: Framework extending window functions for Follow Mode (etc.)., martin rudalics, 2015/11/09
- Re: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/09
Re: Framework extending window functions for Follow Mode (etc.)., Artur Malabarba, 2015/11/07