From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: The future of Follow Mode - a proposal. Date: Sat, 20 Feb 2016 15:05:16 +0200 Message-ID: <83wppzo7lf.fsf@gnu.org> References: <20160218195630.GA2697@acm.fritz.box> <837fi1u5qt.fsf@gnu.org> <20160219142522.GA3193@acm.fritz.box> <83povsr8cc.fsf@gnu.org> <20160219181834.GC3193@acm.fritz.box> <83io1kr12k.fsf@gnu.org> <20160220124415.GA1758@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1455973565 12964 80.91.229.3 (20 Feb 2016 13:06:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Feb 2016 13:06:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 20 14:06:04 2016 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 1aX7EY-000081-G1 for ged-emacs-devel@m.gmane.org; Sat, 20 Feb 2016 14:06:02 +0100 Original-Received: from localhost ([::1]:60964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX7EX-0004qO-PL for ged-emacs-devel@m.gmane.org; Sat, 20 Feb 2016 08:06:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX7E8-0004pE-Nd for emacs-devel@gnu.org; Sat, 20 Feb 2016 08:05:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aX7E4-0005EO-7k for emacs-devel@gnu.org; Sat, 20 Feb 2016 08:05:36 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX7E3-0005EJ-U9; Sat, 20 Feb 2016 08:05:32 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1535 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aX7E3-0003BC-8t; Sat, 20 Feb 2016 08:05:31 -0500 In-reply-to: <20160220124415.GA1758@acm.fritz.box> (message from Alan Mackenzie on Sat, 20 Feb 2016 12:44:15 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:200305 Archived-At: > Date: Sat, 20 Feb 2016 12:44:15 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > The functions we talk about currently don't know what they are invoked > > for. Your envisioned changes imply that they should behave > > differently depending on whether the results will be used for layout > > of the current window or the next/previous window in a group. That's > > part of the changes I had in mind. They are not trivial. But without > > them, what you want to do will not work reliably. > > How about adding an extra boolean parameter to the move_it_* functions, > perhaps called `physical', which when set would mean the function would > have to adjust its iterator when crossing a window boundary, when not set > would work the same way as it currently does? `vertical-motion' would > also need this extra &optional parameter, possibly a few other defuns, > too. I don't think it's a boolean. It should be the buffer position where the window should be switched. So probably 2 parameters, for the beginning and end of the window. Maybe also the window to switch to. And then you need to implement the handling of these new arguments. > There are around 150 calls to move_it_*. I'm guessing that most of these > would set `physical' to false, perhaps more of the ones in window.c would > use true. Maybe, I don't know. The problem is that these functions are called in several layers, and all of them will have to know about these new arguments. Also, some utility functions, like pos_visible_p, are called in different situations, so the caller will have to supply those arguments as required in each case. > > > As an example, `compute_window_start_on_continuation_line' would have to > > > use the dimensions of the previous window to determine the window-start. > > > Jiggling the various windows around after text changes or scrolling is > > > going to be the hard part of the coding. > > > Yes, and the result will be non-trivial changes in the overall logic, > > because redisplaying a window will no longer be independent of other > > windows. > > Yes. This is what is currently implemented in Follow Mode. No, I mean that redisplay of all the windows in a group will have to be done in one go, not one window at a time.