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: Sat, 17 Oct 2015 11:57:38 +0000 Message-ID: <20151017115738.GA2522@acm.fritz.box> References: <20151001110204.GB2515@acm.fritz.box> <83egheaj9e.fsf@gnu.org> <20151015181642.GA6467@acm.fritz.box> <834mhr99e8.fsf@gnu.org> <20151016095535.GA2779@acm.fritz.box> <83a8ri67jg.fsf@gnu.org> <20151016181249.GC2779@acm.fritz.box> <837fmm65bl.fsf@gnu.org> <20151016201238.GD2779@acm.fritz.box> <83twpp51xz.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 1445082983 1733 80.91.229.3 (17 Oct 2015 11:56:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 11:56:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 13:56:14 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 1ZnQ5u-0006F4-5u for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 13:56:14 +0200 Original-Received: from localhost ([::1]:57930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQ5t-0001AD-0z for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 07:56:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQ5p-0001A8-0F for emacs-devel@gnu.org; Sat, 17 Oct 2015 07:56:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnQ5j-0007Io-W8 for emacs-devel@gnu.org; Sat, 17 Oct 2015 07:56:08 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:48801) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQ5j-0007Ib-Mm for emacs-devel@gnu.org; Sat, 17 Oct 2015 07:56:03 -0400 Original-Received: (qmail 87355 invoked by uid 3782); 17 Oct 2015 11:56:01 -0000 Original-Received: from acm.muc.de (p548A55E0.dip0.t-ipconnect.de [84.138.85.224]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 17 Oct 2015 13:56:01 +0200 Original-Received: (qmail 7871 invoked by uid 1000); 17 Oct 2015 11:57:38 -0000 Content-Disposition: inline In-Reply-To: <83twpp51xz.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:191817 Archived-At: Hello, Eli. On Sat, Oct 17, 2015 at 11:33:44AM +0300, Eli Zaretskii wrote: > > Date: Fri, 16 Oct 2015 20:12:38 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > Will the following algorithm work: > > No, it won't. If it did, I'd be somewhat annoyed, having spent so much > > time thinking about it, drawing diagrams, and debugging over the last > > week or so. ;-) > > > . compute the horizontal difference, in pixels, between the position > > > which xdisp would use as window-start and the actual window-start > > > (the value should always be positive); let's call the result N Just a point I missed last night: N could be either positive or negative, depending on whether the "exact" window start is just before or just after the "xdisp" window start. A situation where N would be negative is: 3. B---------------WS---A--------------L1---A2---------\nC---------C2--- , where the "xdisp" window start would be at A, not B. (BTW, I'm not all that enthusiastic about my terminology "exact" and "xdisp" here, and if anybody could come up with better suggestions, I'd welcome it. But "exact" and "xdisp" are, at the very least, quite short.) > > > . let Fvertical_motion do its thing exactly as it does now > > > . move N more pixels to the right, i.e. in the direction of > > > increasing the X coordinate, or to the end of line, if it ends > > > before that coordinate > > > If this should work, then all you need is to implement the 1st bullet, > > > which is very easy, nothing as complicated as your > > > maybe_move_to_exact_bol. It should just call move_it_in_display_line > > > to get to the actual window-start, and save the X coordinate wehen it > > > gets there. > > Here's an example why it won't work: > > nlines = 3 > > 1. B---WS-------------A---L1------------\nC----------C2---------C3----- > > ^ T it > > o - Point starts at A, and (since this is already the start of an xdsip > > line) Fvertical_motion moves it forward three lines to C3. > > o - What we want to happen is for point to be first set back to the > > (exact) BOL, WS, then moved forward three lines to C2. > > o - So, before applying the N pixel correction, the actual and target > > final positions are already a complete line apart, regardless of the > > number of characters (or pixels) on either of these lines. > Starting from a BOL is a special case that can be handled by special > code. Will the algorithm I suggested work in all other cases? Starting at a(n xdisp) BOL isn't a special case: anywhere between A (inclusive) and L1 (exclusive) is equivalent. I think it's probably more accurate to say that there are cases that your algorithm will handle correctly. For example, in diagram 1, move PT a few characters to the right, so that it reaches (or passes) L1. Fvertical_motion's handling of the situation is the same as before (it still moves back to A, then forward to C3), but the target BOL has become C3. In the (common) case where the target BOL is at or after C, adjusting horizontally by N pixels will always be wrong. The adjustment we need is to the next, or the previous (common) BOL. My feeling is that there is no general case from which a tiny number of special cases deviate. Rather, there are just several special cases. > > By making the pertinent text line just a little bit longer, we could end > > up with this (note the extra BOL at A2): > > nlines = 3 > > 2. B---WS-------------A---L1------------A2-\nC---------C2--------C3--- > > ^ it,T > > o - Now Fvertical_motion puts `it' bang on target. > > o - To adjust the final position by N pixels would make it wrong. > No, it won't: move_it_in_display_line always stops at the end of the > line, even if the goal X coordinate is not yet reached. It does not > move to the next screen line, as you seem to assume. > > I see no alternative to counting BOLs of each type up to the point of > > coincidence, C. It is possible this might be done with more finesse > > that I've managed so far, but be done it must. > To find out whether we moved past a newline, you can call > reseat_at_next_visible_line_start. > My analysis of what you described concluded, perhaps wrongly, that the > essence of the problem is the constant offset between the "actual" > beginning of each screen line and the display engine's idea of that > beginning. This constant offset is limited to the first physical line > of the window; once we get past the first newline, the offset > disappears. Is this conclusion correct? I don't think so. That constant offset, N, is indeed relevant in the first text line in the window. But after the first newline, whether or not we have to move one up or down from Fvertical_motion's position is critically dependent upon the arrangement of exact and xdisp BOLs in that first text line. For example, although diagrams 1 and 2 have the same (positive) N, we need to shift Fvertical_motion's end position by 1 line in diagram 1, but not in diagram 2. -- Alan Mackenzie (Nuremberg, Germany).