From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: The future of Follow Mode - a proposal. Date: Fri, 19 Feb 2016 15:56:22 +0100 Message-ID: References: <20160218195630.GA2697@acm.fritz.box> <837fi1u5qt.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1143f0ccbaf765052c20afd2 X-Trace: ger.gmane.org 1455893799 6602 80.91.229.3 (19 Feb 2016 14:56:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Feb 2016 14:56:39 +0000 (UTC) Cc: Alan Mackenzie , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 19 15:56:34 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 1aWmTw-0004yk-I6 for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 15:56:32 +0100 Original-Received: from localhost ([::1]:52927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWmTv-0004UO-TO for ged-emacs-devel@m.gmane.org; Fri, 19 Feb 2016 09:56:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWmTo-0004T8-MX for emacs-devel@gnu.org; Fri, 19 Feb 2016 09:56:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWmTn-0007YA-Lk for emacs-devel@gnu.org; Fri, 19 Feb 2016 09:56:24 -0500 Original-Received: from mail-vk0-x235.google.com ([2607:f8b0:400c:c05::235]:35210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWmTn-0007Y5-Fk; Fri, 19 Feb 2016 09:56:23 -0500 Original-Received: by mail-vk0-x235.google.com with SMTP id e6so76030416vkh.2; Fri, 19 Feb 2016 06:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yhq+FxbFzJldoP+frAYvvUBM2lPYR4pgK9PfRcQa7ts=; b=EDBWaQkmtTUcj+3jDHEw4fRmgRRWk/JWOvM/tNG7s1JRL+yqYyeM5+ml08RBxSxAT/ h9Ke8ckSIhWXALiE3wxhYYxEv07XB4hZHWcIUz6vbn0X6htVjydfkTmVBpF+wT9mNMF0 6f8xR7mmKmNwte4Hf3UsxVyQJPid3BoyyF452DTn7PaaWB0YPSGl2yPQ2XpTHbbQ0CqC 2zO4L6GxN7NlWBwJmu0Ndmc1rdevjr2uh/jyffM3/VmrYy/kKKBSlzmsu1Fhw8I+ja1h KWl6nbPk/+JnrZKVVBdTw3RLwc8ecRfwqADenv5Z0hrsNh85CdLIGqf5e8521VuDCWGg 0KSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Yhq+FxbFzJldoP+frAYvvUBM2lPYR4pgK9PfRcQa7ts=; b=jDRRzOY4n3z7NJFX/X0VFiNl1zYVzq6WQoaNt5fUHBA4Pull83qWUGqLFtCNzXvTx7 q/NgEc3i9fLZmZ9sgvcd5Xn7mus1gJnhZNNsUxeI6mFjezLVs+wPRrfCOCoztTW4QT41 ksC6pjgzHDhsYqXBvOs2dyPJGKvZTD2/9d3ixs+VrmCoHbdqy/xo572JoIazhAV73Bp6 RWo2m/87DkeNRcTkOFjizFlHo16ZZVdt/g4N3Ep6KTvVacL9eFpDU7kKY7NSgczjucBj yj8yXg7wwfgOOxe829ZqxoCEG9J5OZKJlfnd+exWYpk0p/nQwTmb4GoCIrt0B4mQasmh aRfw== X-Gm-Message-State: AG10YOTTOLDVLzGHXLWHrMJBPu05okssJXMlwAdyXB/g+Azo4BHsl88ZDybjCM0ZoQLlVxXgKDdXPuNMoxwcjQ== X-Received: by 10.31.56.140 with SMTP id f134mr11394629vka.23.1455893782392; Fri, 19 Feb 2016 06:56:22 -0800 (PST) Original-Received: by 10.31.214.131 with HTTP; Fri, 19 Feb 2016 06:56:22 -0800 (PST) In-Reply-To: <837fi1u5qt.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::235 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:200214 Archived-At: --001a1143f0ccbaf765052c20afd2 Content-Type: text/plain; charset=UTF-8 > > IMO, moving the code to C will solve only the marginal aspects of > this. The main problem -- the fact that the current display engine > doesn't support windows of unequal width -- cannot be solved without > deep changes. We need to at least design these changes first, so that > we have a clear idea how to solve these issues. FWIW, I thought about > this for a while, and didn't see any easy way of doing it. > > If we abandon the design goal of supporting windows of unequal width, > the problem becomes much easier. 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. 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. 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 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.) -- Anders --001a1143f0ccbaf765052c20afd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMO, moving the code to C will solve only the ma= rginal aspects of
this.=C2=A0 The main problem -- the fact that the current display engine doesn't support windows of unequal width -- cannot be solved without deep changes.=C2=A0 We need to at least design these changes first, so that=
we have a clear idea how to solve these issues.=C2=A0 FWIW, I thought about=
this for a while, and didn't see any easy way of doing it.

If we abandon the design goal of supporting windows of unequal width,
the problem becomes much easier.

Windows of= unequal width is something that we need to live with, at least if follow-m= ode is something that a user can enable without affecting the layout of a f= rame, like today.

Anyway, wouldn't it be possi= ble for the display engine to do the layout of the leftmost window (of a fo= llow mode window group) using the normal system for finding a suitable star= t location on even line boundaries. The rest of the windows in the window g= roup could then use the end position of the previous window.

=
In fact, I think it could be supported today from lisp if only i= t 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 win= dow-by-window basis. In the case of follow-mode, the leftmost window should= keep it enabled, whereas the rest should disable this feature.
<= br>
(The only thing that wouldn't work is if a multi-width ch= aracter (like control-l "^L") is partially visible. It will conti= nue to work like today, with "^" visible at the end of one window= and "^L" at the start of the next.)

=C2= =A0 =C2=A0 -- Anders

--001a1143f0ccbaf765052c20afd2--