From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Framework extending window functions for Follow Mode (etc.). Date: Sun, 08 Nov 2015 19:10:51 +0100 Message-ID: <563F902B.80102@gmx.at> 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> <20151108121332.GB1962@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447006296 12945 80.91.229.3 (8 Nov 2015 18:11:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 18:11:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 19:11:25 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 1ZvUR1-0006Jm-Gv for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 19:11:23 +0100 Original-Received: from localhost ([::1]:48388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvUR0-0004sC-Pb for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 13:11:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvUQn-0004s5-7q for emacs-devel@gnu.org; Sun, 08 Nov 2015 13:11:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvUQj-0005P9-Rf for emacs-devel@gnu.org; Sun, 08 Nov 2015 13:11:09 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:54884) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvUQj-0005O9-I9 for emacs-devel@gnu.org; Sun, 08 Nov 2015 13:11:05 -0500 Original-Received: from [192.168.1.100] ([213.162.68.71]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MXZw6-1ZyKeG39MM-00WYVD; Sun, 08 Nov 2015 19:11:02 +0100 In-Reply-To: <20151108121332.GB1962@acm.fritz.box> X-Provags-ID: V03:K0:qAJsqr1PVeJy++eWOFZ2z+5vqmAJ2Q4wSXkC9hVXas7xlHSy9Vk l9LRaPfXazdgGP67SaHfN7y+A6UIl8lUzaxNq88oaVbuhX4q/i3UO4qOeEbw3GvMeKhcSow 11wqS/gCiEosK2hxjptmBMuklRS2TSzgQV5J3w8PYhtmOTPe5Vg+B5kDjdfKZyjV5HDvJRf KtyHgB2boJNUF1eLW61yg== X-UI-Out-Filterresults: notjunk:1;V01:K0:O9rnf5TOBSU=:jeJALocY7JtrylNIdEi9aY MYqi79BN4HjTH6SWCUhlHA5GrcLxbpmjovjv5fA1sXatHtjvHuPE4pdehbQjdAq4ViO4lc5Qq Z9v4rPxYGtZvzzi8gKD3MnosAZbeZXn6Nu/NVn8k00WjoS7xrhxZM3L4oOff3NNAuS0VuXuLk +zuAZb0rt0gTQIQvgacjz/9bkAAtRNGztv2ydr3jwtQcgFpD2ZKfanMAwZTFu2tFzVU1+5ZJl /3JqVwzRxQWHE1bGA1yxXms+5cDEiOOo34riWFI3j6Sl6ZVIKEPJ7ThHpgqo6Q9rDGX2mKeOX kHKRLcoTJLvcfwJerAqN4bZ3NHHjRI0DFABwucQXE1rchu8dB3/YBrC1KqSP0HQiVKdm0PWhw wz/Afq6+aLfH7086UKn0ttdu0xWNkY/ZzLH8H1m5s0xn/qr4DixG5NP3/RtyhCLqq1BkBG05J D9Q/MKqGSAnrpLvDtioGxgl5qQdy9CXAmeoDalOXlr4zhUTXxS7Si8X6g80VKwPBmep77OVGb KE7T/xSjbQjHSKTFR/2BI6tziBAZzzsTh9fklu18Jq4HK8RJYe+TzEPP7E/RLijKhH4KjMCZy gw6RLc9FWJ3F8Dfaq5/jnRgNSJ9I7XQSs915+s4WXIW1dG4YG1bPj62uDqYX/X7oaMi1oCtnv KqBTXPDeNjin4TbTew+CNK152BX7b8FgowjwTZsa/EkaY9f8+OoQiMQB0jp7LUQYAndMUTYdy bi7uMTRcf96+gBFu5TRXCj/6TDfg8cXKFq4IcLtNCH8NVmRNQLdPu2p4yN9RXG2xPfLCbTyL X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 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:193631 Archived-At: > Well, it's now been renamed `set-window-start-group-function', but > basically, yes. The caller would call `set-window-start' without havi= ng > 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 whol= e > group of windows if there is one". So the idea is that =E2=80=98follow-mode=E2=80=99 sets `set-window-start-= group-function' to say =E2=80=98follow-mode-set-window-start=E2=80=99 which is then calle= d whenever =E2=80=98isearch-mode=E2=80=99 calls =E2=80=98set-window-start=E2=80=99. = Since you don't do this on a per window basis, =E2=80=98follow-mode-set-window-start' can be also call= ed for windows that are not managed by =E2=80=98follow-mode=E2=80=99 probably in= the hope that =E2=80=98follow-mode-set-window-start=E2=80=99 temporarily binds =E2=80=98set-window-start-group-function=E2=80=99 to nil around a nested = call to =E2=80=98set-window-start=E2=80=99. It strikes me as a bad idea that =E2=80=98follow-mode-set-window-start=E2=80=99 has to take care of window= s that are not in =E2=80=98follow-mode=E2=80=99. 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 =E2=80=98set-window-start-group-function=E2=80=99 variable. Your = approach doesn't scale. >> An argument with such a name should be non-nil only in calls by >> =E2=80=98follow-mode=E2=80=99 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. >> =E2=80=98isearch-mode=E2=80=99 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 =E2=80=98set-window-start=E2=80=99 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 =E2=80=98set-window-start=E2=80=99. = 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 somethi= ng > 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 wit= h 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 co= uld >> >> 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 b= e > 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 =E2=80=98follow-mode=E2=80=99. A= s 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 n= o > 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= =2E > It would, of course, also affect external code. =E2=80=98follow-mode-set-window-start=E2=80=99 would have to take care of= that. If you really care about this have =E2=80=98follow-mode-set-window-start=E2=80=99= check a variable like =E2=80=98isearch-mode=E2=80=99 to make sure that it affects= isearch calls only. >> > Also, were Follow Mode to be superseded at any time, then the int= erface >> > 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 =E2=80=98set-window-start=E2= =80=99 and decided that =E2=80=98follow-mode=E2=80=99 is obsolete we'd have up to 13= 2 calls to change back. martin