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: Fri, 19 Feb 2016 18:30:01 +0200 Message-ID: <83mvqwr7cm.fsf@gnu.org> References: <20160218195630.GA2697@acm.fritz.box> <837fi1u5qt.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1455899442 8687 80.91.229.3 (19 Feb 2016 16:30:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Feb 2016 16:30:42 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org To: Anders Lindgren Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 19 17:30:37 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 1aWnwo-0000jF-PD for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 17:30:26 +0100 Original-Received: from localhost ([::1]:53569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWnwo-0002ZW-5X for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 11:30:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWnwg-0002Rm-1Z for emacs-devel@gnu.org; Fri, 19 Feb 2016 11:30:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWnwb-000126-UC for emacs-devel@gnu.org; Fri, 19 Feb 2016 11:30:17 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34141) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWnwb-000122-Q6; Fri, 19 Feb 2016 11:30:13 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3977 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aWnwb-0006hl-4I; Fri, 19 Feb 2016 11:30:13 -0500 In-reply-to: (message from Anders Lindgren on Fri, 19 Feb 2016 15:56:22 +0100) 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:200223 Archived-At: > 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. > 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. 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 -- 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. > 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. 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. 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). > (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.