From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#17453: Framework extending window functions for Follow Mode (etc.). Date: Tue, 17 Nov 2015 22:55:58 +0000 Message-ID: <20151117225558.GC5054@acm.fritz.box> References: <20151108002955.GC1774@acm.fritz.box> <8737wgou4z.fsf@mail.linkov.net> <20151109154124.GC2284@acm.fritz.box> <87611a8x96.fsf@mail.linkov.net> <20151110110823.GB2626@acm.fritz.box> <876119s7fu.fsf@mail.linkov.net> <20151111161914.GB5669@acm.fritz.box> <87egfwca3b.fsf@mail.linkov.net> <56444C48.5000609@gmx.at> <8737wbx9ep.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1447800924 4775 80.91.229.3 (17 Nov 2015 22:55:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 22:55:24 +0000 (UTC) Cc: 17453@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 17 23:55:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Zyp9c-0005RA-Mm for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Nov 2015 23:55:12 +0100 Original-Received: from localhost ([::1]:60992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyp9b-0002EA-T8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Nov 2015 17:55:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyp9X-0002C4-07 for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 17:55:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zyp9S-0005dm-0h for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 17:55:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52396) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyp9R-0005di-To for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 17:55:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zyp9R-0003EJ-Nc for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 17:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Nov 2015 22:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17453 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17453-submit@debbugs.gnu.org id=B17453.144780084412275 (code B ref 17453); Tue, 17 Nov 2015 22:55:01 +0000 Original-Received: (at 17453) by debbugs.gnu.org; 17 Nov 2015 22:54:04 +0000 Original-Received: from localhost ([127.0.0.1]:42104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zyp8W-0003Bt-7G for submit@debbugs.gnu.org; Tue, 17 Nov 2015 17:54:04 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:40956) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zyp8U-0003BU-6D for 17453@debbugs.gnu.org; Tue, 17 Nov 2015 17:54:03 -0500 Original-Received: (qmail 29849 invoked by uid 3782); 17 Nov 2015 22:54:00 -0000 Original-Received: from acm.muc.de (p579E91A5.dip0.t-ipconnect.de [87.158.145.165]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 17 Nov 2015 23:53:59 +0100 Original-Received: (qmail 6583 invoked by uid 1000); 17 Nov 2015 22:55:58 -0000 Content-Disposition: inline In-Reply-To: <8737wbx9ep.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108846 Archived-At: Hello, Juri. On Thu, Nov 12, 2015 at 10:14:22PM +0200, Juri Linkov wrote: > >> Thanks, I'm looking at your changes, and also Cc'ing Martin in the hope > >> that Martin could review your window-related changes as well. > > Glimpsing on the window-related changes I think I have already said > > everything in this thread. Usurpating the term "group" in the sense > > that all windows belonging to a group have to show the same buffer seems > > overly restrictive but I don't want to continue the earlier discussion. > I agree that the cleanest way to add a new feature is not to change window > primitives, but to add it on the top of existing window primitives > by defining a new functional layer with a set of functions having a common > name prefix either 'window-group-' or 'windows-' (used by follow.el in some > places). I am coming around to the idea that the new functions are a better way of implementing this than adding an extra optional parameter to the primitives. The reason is, I have a vision that some time in the medium future, the Follow Mode functionality will come to be implemented directly in the redisplay engine. If we add the extra parameter, it will then be redundant and stick out like a sore thumb. But with functions like `window-group-start', these functions could quietly merge with `window-start', etc., as soon as the display engine stuff is working. I have already implemented (though not committed) the extra functional layer. The names I used were `window*-start', ...., `move-to-window*-line'. Thinking about Anders's comment today that the "*" could easily get lost, .... > Here are existing primitives and two variants of new functions: > (window-start &optional WINDOW) > (windows-start &optional WINDOW) > (window-group-start &optional WINDOW) ...., I now think the best name would be the last of these three, window-group-start. It is not too long, and the phrase "window_group" fits in with all the primitives apart from `recenter'. So we'd need some different naming ideas, perhaps "recenter-group" or "group-recenter". > These new functions could be defined in a new core package with a name like > window-group.el or windows.el, or maybe added to the end of window.el, > and have no follow-specific code. I put them into window.el. It seems like a good place. > Then there is no need in a set of functions like window-start-group-function, > because one function should be enough for a package like follow.el > to declare an active group of windows via follow-all-followers, > or packages other than follow.el using window parameters. > Then window-group/windows functions should take care about all > aspects of handling multiple windows. We don't want Follow Mode to become too tightly coupled with "its users". > So e.g. new function follow-window-start will be window-group-start > taking only follow-all-followers from follow.el, etc. > This means that while adapting other packages to multi-window configurations, > instead of adding the 't' arg to core primitives, we need to add 's' (window -> windows) > or '-group' to the names of the existing function calls. I say the '-group' variant. > The key point is not touching core primitives until we'll be able to > implement a proper display abstraction for window groups such as proposed > a while ago under the name "framelettes". This comment in follow.el also > gives a hint in this direction: > ;; Almost like the real thing, except when the cursor ends up outside > ;; the top or bottom... In our case however, we end up outside the > ;; window and hence we are recentered. Should we let `recenter' handle > ;; the point position we would never leave the selected window. To do > ;; it ourselves we would need to do our own redisplay, which is easier > ;; said than done. (Why didn't I do a real display abstraction from > ;; the beginning?) Yes. By the way, have you had the chance to look at the changes I made to isearch.el in the scratch/follow branch? -- Alan Mackenzie (Nuremberg, Germany).