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: The future of Follow Mode - a proposal. Date: Fri, 19 Feb 2016 18:45:27 +0000 Message-ID: <20160219184527.GD3193@acm.fritz.box> References: <20160218195630.GA2697@acm.fritz.box> <837fi1u5qt.fsf@gnu.org> <83mvqwr7cm.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1455907404 28039 80.91.229.3 (19 Feb 2016 18:43:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Feb 2016 18:43:24 +0000 (UTC) Cc: Anders Lindgren , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 19 19:43:16 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 1aWq1J-0007pi-Sx for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 19:43:14 +0100 Original-Received: from localhost ([::1]:54587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWq1J-0006d9-BG for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 13:43:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWq1F-0006a5-CS for emacs-devel@gnu.org; Fri, 19 Feb 2016 13:43:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWq1A-0007IG-A5 for emacs-devel@gnu.org; Fri, 19 Feb 2016 13:43:09 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:47872) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWq1A-0007Hx-0E for emacs-devel@gnu.org; Fri, 19 Feb 2016 13:43:04 -0500 Original-Received: (qmail 26900 invoked by uid 3782); 19 Feb 2016 18:43:02 -0000 Original-Received: from acm.muc.de (p548A4E9B.dip0.t-ipconnect.de [84.138.78.155]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 19 Feb 2016 19:43:01 +0100 Original-Received: (qmail 28816 invoked by uid 1000); 19 Feb 2016 18:45:27 -0000 Content-Disposition: inline In-Reply-To: <83mvqwr7cm.fsf@gnu.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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:200235 Archived-At: Hello, Eli. On Fri, Feb 19, 2016 at 06:30:01PM +0200, Eli Zaretskii wrote: > > Date: Fri, 19 Feb 2016 15:56:22 +0100 > > From: Anders Lindgren > > Cc: Alan Mackenzie , emacs-devel > > Windows of unequal width is something that we need to live with, at > > least if follow-mode is something that a user can enable without > > affecting the layout of a frame, like today. > My suggestion is that enabling the mode will equalize the width of all > the windows under Follow mode. This would sort of work in the usual case, but in the general case, arbitrary windows, not necessarily covering a nice rectangular area would be involved. It is not simple to adjust such an arbitrary set to make them all the same width. > > Anyway, wouldn't it be possible for the display engine to do the > > layout of the leftmost window (of a follow mode window group) using > > the normal system for finding a suitable start location on even line > > boundaries. The rest of the windows in the window group could then > > use the end position of the previous window. > This would mean the order in which we display windows will have to be > forced to follow the Follow mode order. Moreover, it would mean that > the decisions of whether to redisplay a certain window will now have > to consider other windows, something that doesn't happen today. It doesn't happen in the display engine, no, but it happens at the Lisp level in Follow Mode. It would be more efficient in every sense if it were actually done by the display engine. > Moreover, the starting point of the window is just the tip of the > iceberg. The display engine uses the move_it_* family of functions to > decide where the window starts and ends, when to scroll the window, > whether point is visible or not, etc. We also use these functions for > user-level window scrolling and in vertical-motion. All of that code > assumes that the window width doesn't change beyond window edges. > Invalidating this assumption wreaks havoc in many places, so these > functions will have to be rewritten to take the fact that text in the > next window uses a different width. See the discussion of > vertical-motion we had with Alan several months ago -- :-) I've still got the code somewhere which allows an arbitrary window-start to be set. That wasn't the difficult bit. > while working on the patch I presented there, I realized that this > feature is unworkable as long as the display engine was not taught to > handle unequal-width windows. The display engine would need to handle window _groups_. The variable width part would be part of this. > > In fact, I think it could be supported today from lisp if only it was > > possible to disable the part of the display engine that ensures that > > the window start position is an even multiple of the window width, on > > a window-by-window basis. In the case of follow-mode, the leftmost > > window should keep it enabled, whereas the rest should disable this > > feature. I tried that last autumn. It was more complicated than I'd imagined. > The current display engine likes the window start point to be at the > beginning of a physical line. Lifting this restriction also requires > changes, because currently, even if you trick the display into using a > starting point in the middle of a line, it is likely to reset that to > the line beginning on the next redisplay cycle. This will cease to be a problem if the display engine can handle window groups. The display engine already allows windows to start in continuation lines. It's just how you calculate the start of such a line. > IOW, without changes in the display engine, we will be making a series > of questionable kludges one upon the other. That's hardly the way to > develop Emacs. > I understand the desire to avoid significant changes in the design of > the display engine, but I see no way this could work reliably, unless > we force all the Follow-mode windows to be of equal width (in > character units). I agree that the display engine would need significant modification. > > (The only thing that wouldn't work is if a multi-width character > > (like control-l "^L") is partially visible. It will continue to work > > like today, with "^" visible at the end of one window and "^L" at the > > start of the next.) > Control characters are not the only ones which will bump into this. This surely occurs already, and might not be relevant to the exercise. -- Alan Mackenzie (Nuremberg, Germany).