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

[Eli Zaretskii]

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