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 window start at a meaningless point within a line." Date: Sun, 1 Nov 2015 15:23:54 +0000 Message-ID: <20151101152354.GD2768@acm.fritz.box> References: <83oafx4qsb.fsf@gnu.org> <83lhb14o6e.fsf@gnu.org> <83k2ql4lsy.fsf@gnu.org> <20151018150052.GD1639@acm.fritz.box> <83lhb0hy0h.fsf@gnu.org> <20151019102755.GB2438@acm.fritz.box> <20151027134025.GA2401@acm.fritz.box> <83fv0w41dg.fsf@gnu.org> <20151028131505.GB2538@acm.fritz.box> <8337wryy0x.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 1446391363 23593 80.91.229.3 (1 Nov 2015 15:22:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Nov 2015 15:22:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 01 16:22:27 2015 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 1ZsuSf-0002mz-HS for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 16:22:25 +0100 Original-Received: from localhost ([::1]:37735 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsuSe-0001nZ-Ut for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 10:22:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsuSR-0001nS-LC for emacs-devel@gnu.org; Sun, 01 Nov 2015 10:22:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZsuSO-0003ys-HZ for emacs-devel@gnu.org; Sun, 01 Nov 2015 10:22:11 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:62893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsuSO-0003yh-7E for emacs-devel@gnu.org; Sun, 01 Nov 2015 10:22:08 -0500 Original-Received: (qmail 38479 invoked by uid 3782); 1 Nov 2015 15:22:06 -0000 Original-Received: from acm.muc.de (p548A4E61.dip0.t-ipconnect.de [84.138.78.97]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 01 Nov 2015 16:22:05 +0100 Original-Received: (qmail 3708 invoked by uid 1000); 1 Nov 2015 15:23:54 -0000 Content-Disposition: inline In-Reply-To: <8337wryy0x.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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:193065 Archived-At: Hello, Eli. On Sat, Oct 31, 2015 at 03:21:02PM +0200, Eli Zaretskii wrote: > > Date: Wed, 28 Oct 2015 13:15:05 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > After applying the patch, to test things, in X (?or windows) > > o - Start emacs -Q. > > o - Load utilities.el. > > o - Visit fragment.el. > > o - Using the mouse, make the frame wide enough for two side by side > > windows of width 79 and 80. > > o - C-x 3. > > o - Fiddle about with the mouse, M-{, M-}, until the windows are 79, and > > 80 wide (`window-body-width' is your friend, here). > > o - Scroll the buffer until L162 straddles window 1 and window 2, with > > two display lines in each window. (S-/, C-S-/ > > from utilies.el are handy, here). > > First of all, note that in L162, all characters are displayed exactly > > once. This is the purpose of this change. > > With point in W2, note that C- doesn't go to the beginning of > > the window, and C- doesn't go to the end. The actual end > > positions are a line out in both cases. With point in the split line, > > note that vertical-motion (C-u C-c m) doesn't go to the right > > places, even when the target line is below the split line. Typing > > and also produce interesting effects. > > Using M-{ or M-}, make W1 80 wide, and W2 79 wide. Scroll the windows > > up and down, back to the same place, to ensure that Follow Mode has > > resynchronised its windows[*]. Now repeat the experiments of the > > previous paragraph. If anything, the results now are even worse. > The patch below should go a long way towards solving these problems. > The only issue I left unsolved is exposed when typing C-p on the > second screen line of the right-side window: you will see that it > doesn't succeed in keeping the visual column. Solving this is left as > an exercise ;-) ;-). Sometimes it doesn't even go to the right line (i.e. when there are more or fewer "actual" lines than "xdisp" lines). To detect this situation necessarily involves reseat_at_window_start followed by moving forward, counting (display) line starts, in some fashion. Do you agree? To move to the right column of the line necessarily involves knowing where the "actual" BOL is. This also involves a reseat_at_window_start and moving forward lines. Do you agree this one, too? At the moment, I can't see how post analysis (i.e. analysis after Fvertical_motion has done move_it_by_lines (&it, nlines)) can be avoided. In this line of thinking, considering how bidi complicates the order of PT, end position, and various BOLs, it might be very convenient to enhance move_it_in_display_line_to to take TWO (or even several) to_charpos parameters, such that the function would stop after reaching either one of them. (Naturally, there would be some convention for the usual case of calling it with just one to_charpos.) Although this enhancement would be tedious, it would surely not be difficult. With such a function, we could scan through the buffer with both PT and end_position as to_charpos's. What do you think? > I hope the changes I made and the comments to those changes will speak > for themselves, and show how to solve such problems. I like your idea for solving the "going back over the top of the window" problem. Is there any guarantee that w->prev will actually be the window "to the left of" w (whatever that might mean)? > Please note that there's a very serious underlying problem here: the > move_it_* functions and all their callers assume that moving beyond > above or below the window keeps the same window dimensions, in > particularly its width. Follow mode violates this assumption, because > moving from the left-side to the right-side window or vice versa can > change the width. Accounting for this would need very deep changes in > the above mentioned functions. For now, I avoided that, and the patch > below is just a band-aid. If it works well enough in practice, maybe > we can avoid the surgery. But in general, I must say that fixing what > you are trying to fix is an ambitious undertaking; perhaps it would be > better to make sure the two windows are always the same width, using > pixel-wise resizing where necessary. As already said, this would be sub-optimal for ttys, where the total width is fixed, and tends not to be a number of the form 2n+1 or 3n+2. -- Alan Mackenzie (Nuremberg, Germany).