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 15:34:44 +0300 Message-ID: <83oafx4qsb.fsf@gnu.org> 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> <20151017115738.GA2522@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1445085314 1543 80.91.229.3 (17 Oct 2015 12:35:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 12:35:14 +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 14:35: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 1ZnQhQ-0005oa-V1 for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 14:35:01 +0200 Original-Received: from localhost ([::1]:58170 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQhQ-0004xw-8C for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 08:35:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQhC-0004xr-Nv for emacs-devel@gnu.org; Sat, 17 Oct 2015 08:34:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnQh9-00022n-9i for emacs-devel@gnu.org; Sat, 17 Oct 2015 08:34:46 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:35521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQh8-00022e-74 for emacs-devel@gnu.org; Sat, 17 Oct 2015 08:34:42 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NWD00A006Q3UQ00@mtaout27.012.net.il> for emacs-devel@gnu.org; Sat, 17 Oct 2015 15:30:34 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWD003TZ6QXXP50@mtaout27.012.net.il>; Sat, 17 Oct 2015 15:30:34 +0300 (IDT) In-reply-to: <20151017115738.GA2522@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.183 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:191820 Archived-At: > 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. It cannot start at A, because that would put point outside of the window. IOW, we always compute the offset relative to the BOL of a screen line that includes the "actual" window start. > (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. > > 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.) > > 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? 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. 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 . 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?