From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Framework extending window functions for Follow Mode (etc.). Date: Sun, 8 Nov 2015 12:13:32 +0000 Message-ID: <20151108121332.GB1962@acm.fritz.box> References: <20151105192905.GA7986@acm.fritz.box> <563DFBF8.9030903@gmx.at> <20151107135726.GC1770@acm.fritz.box> <563E163A.6000403@gmx.at> <20151107161201.GD1770@acm.fritz.box> <563E2FD7.5030903@gmx.at> <20151107185551.GB1774@acm.fritz.box> <563F1464.4050000@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1446984719 12521 80.91.229.3 (8 Nov 2015 12:11:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 12:11:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 13:11:50 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZvOp4-0007Qf-0E for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 13:11:50 +0100 Original-Received: from localhost ([::1]:47081 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvOp3-0006gn-02 for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 07:11:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvOox-0006g7-Sg for emacs-devel@gnu.org; Sun, 08 Nov 2015 07:11:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvOou-0005m7-I3 for emacs-devel@gnu.org; Sun, 08 Nov 2015 07:11:43 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:56377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvOou-0005lr-8U for emacs-devel@gnu.org; Sun, 08 Nov 2015 07:11:40 -0500 Original-Received: (qmail 59948 invoked by uid 3782); 8 Nov 2015 12:11:38 -0000 Original-Received: from acm.muc.de (p548A4846.dip0.t-ipconnect.de [84.138.72.70]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 08 Nov 2015 13:11:37 +0100 Original-Received: (qmail 2413 invoked by uid 1000); 8 Nov 2015 12:13:32 -0000 Content-Disposition: inline In-Reply-To: <563F1464.4050000@gmx.at> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193601 Archived-At: 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).