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 window start at a meaningless point within a line." Date: Sat, 17 Oct 2015 11:33:44 +0300 Message-ID: <83twpp51xz.fsf@gnu.org> References: <20151001094138.GA2515@acm.fritz.box> <83h9maao7w.fsf@gnu.org> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1445070850 23381 80.91.229.3 (17 Oct 2015 08:34:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 08:34:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 10:34:01 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 1ZnMwA-0004Un-OK for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 10:33:59 +0200 Original-Received: from localhost ([::1]:57512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnMw9-00088b-SF for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 04:33:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnMvx-00087W-HJ for emacs-devel@gnu.org; Sat, 17 Oct 2015 04:33:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnMvu-0005gG-CH for emacs-devel@gnu.org; Sat, 17 Oct 2015 04:33:45 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:34190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnMvt-0005g5-W6 for emacs-devel@gnu.org; Sat, 17 Oct 2015 04:33:42 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NWC00600VM6G300@mtaout28.012.net.il> for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:32:57 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWC003XVVQWQL20@mtaout28.012.net.il>; Sat, 17 Oct 2015 11:32:57 +0300 (IDT) In-reply-to: <20151016201238.GD2779@acm.fritz.box> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:191813 Archived-At: > 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 > > > . 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? > 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?