Re: "... the window start at a meaningless point within a line."

[Alan Mackenzie]

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: address@hidden
> > From: Alan Mackenzie <address@hidden>

> > > > >   . 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).