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 15:30:10 +0000 Message-ID: <20151017153010.GB2522@acm.fritz.box> References: <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> <20151017115738.GA2522@acm.fritz.box> <83oafx4qsb.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 1445095755 20505 80.91.229.3 (17 Oct 2015 15:29:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 15:29:15 +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 17:29:07 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 1ZnTPu-0004YC-Nt for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 17:29:07 +0200 Original-Received: from localhost ([::1]:58663 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTPu-00051B-2z for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 11:29:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTPS-0004vG-Q7 for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:28:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnTPP-00022J-Fn for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:28:38 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:42613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTPP-00021a-2f for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:28:35 -0400 Original-Received: (qmail 34820 invoked by uid 3782); 17 Oct 2015 15:28:33 -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 17:28:32 +0200 Original-Received: (qmail 17509 invoked by uid 1000); 17 Oct 2015 15:30:10 -0000 Content-Disposition: inline In-Reply-To: <83oafx4qsb.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:191837 Archived-At: Hello, Eli. On Sat, Oct 17, 2015 at 03:34:44PM +0300, Eli Zaretskii wrote: > > Date: Sat, 17 Oct 2015 11:57:38 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > > > . 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. > No, it is always positive, because in my definition the xdisp start is > at B. You wrote ".... the position which xdisp would use as window-start ...". This position is either A or B, whichever is closer to the requested WS in `set-window-start'. The code which calculates it is (before my patch) in compute_window_start_on_continuation_line, called directly from redisplay_window. In my patch, I extracted get_window_start_on_continuation_line from the above function, and call it from Fvertical_motion to determine this position. We could redefine the "xdisp window start" as always being at B, but that would involve sometimes having to go a line backward from the position returned by get_window_start_on_continuation_line. I'm not convinced that this redefinition would be more helpful than confusing. I think if we were to do this, then we should use a more appropriate term than "xdisp window start". > It cannot start at A, because that would put point outside of the > window. The redisplay code is actually quite happy about point being at WS when A is the "xdisp window start" (I've tried it out, many times). I think this code uses w->start to test whether point is "outside the window". > IOW, we always compute the offset relative to the BOL of a screen line > that includes the "actual" window start. OK, I'll take that as a given for the rest of this email. > > (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.) > "Exact" is a problematic word; I've been using "actual" instead. Yes, I think that's a little bit better. If it ever comes to the point where my existing code (however modified) looks like getting committed, I'll change all the comments and variable names to "*actual*". > > > 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. > After the correction of the definition of the "xdisp" BOL above, do > you still disagree that only starting from a BOL is special? > (Actually, I now think that even that situation isn't special, see > below.) I was never actually convinced that even in the interval [A L1) was special in any way. > > > 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. > Once again, do you still think this after correcting the definition of > the "xdisp" window start? I'll have to study that more carefully and get back to you. But intuitively, I still think that what I said holds. > Btw, I was wrong in that the correction involves movement to the > right. It actually calls for a movement to the left, which is > slightly more complicated (move_it_* functions cannot do that, so you > need to go to the beginning of a screen line first), but not too > complex. I'll have to draw another picture, here. (I'll get you drawing these pictures too, before the end of this conversation. :-) nlines = -1 4. B---WS------------A---L1------------A2------------L2-----\nC----- it T ^ Here, if point starts at L2, our target is clearly L1, one line back from the "actual" BOL we start from. Fvertical_motion first moves back to the previous "xdisp" BOL, A2, then to the "xdisp" BOL before that, A1. Our correction would be N pixels to the _right_, as you originally stated. On the other hand, if our starting point is one character back, nlines = -1 5. B---WS------------A---L1------------A2------------L2-----\nC----- T it ^ , then our target is now WS, but Fvertical_motion behaves exactly the same, putting `it' at A. So now our correction is (window_width - N) characters backwards. Or, put another way we need to go a line backwards (to B) and then N pixels forwards. I thus don't agree that the N pixel correction involves movement to the right. So, even when our target "actual" BOL is on the first text line on the window, we need to pay attention to our exact starting position - in particular, whether or not there is an "actual" BOL between the previous "xdisp" BOL and point. > So now I think that the problem can be solved as follows: > . if Fvertical_motion's code without changes ends up before the > first newline that follows the window-start, you don't need to do > anything, because Fvertical_motion does exactly what you want in > that case Er, hang on. By "before" I understand "at a smaller buffer position than". This is surely the case where we need the N pixel adjustment, either on the line Fv_m puts us on, or the previous one. > . otherwise Fvertical_motion will either end up on the screen line > before the goal, or will be on the right screen line, but to the > right of the goal column, and a correction should be applied by > moving point to the left > Do you agree? Emphatically no. It is essential to analyse the starting position too, as illustrated by the difference between examples 4 and 5. I think you got the binary criterion there reversed, and really meant "if Fv_m's code without changes ends up AFTER the first newline ....". But in this case, sometimes Fv_m takes us to the correct target line, sometimes it's one line out. (See example 1 in my email from Fri, 16 Oct 2015 20:12:38 +0000). -- Alan Mackenzie (Nuremberg, Germany).