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

[Alan Mackenzie]

Hello, Eli.

On Sat, Oct 17, 2015 at 11:33:44AM +0300, Eli Zaretskii wrote:
> > Date: Fri, 16 Oct 2015 20:12:38 +0000
> > Cc: address@hidden
> > From: Alan Mackenzie <address@hidden>

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

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.

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

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

Starting at a(n xdisp) BOL isn't a special case: anywhere between A
(inclusive) and L1 (exclusive) is equivalent.  I think it's probably more
accurate to say that there are cases that your algorithm will handle
correctly.

For example, in diagram 1, move PT a few characters to the right, so that
it reaches (or passes) L1.  Fvertical_motion's handling of the situation
is the same as before (it still moves back to A, then forward to C3), but
the target BOL has become C3.  In the (common) case where the target BOL
is at or after C, adjusting horizontally by N pixels will always be
wrong.  The adjustment we need is to the next, or the previous (common)
BOL.

My feeling is that there is no general case from which a tiny number of
special cases deviate.  Rather, there are just several special 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?

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.

For example, although diagrams 1 and 2 have the same (positive) N, we
need to shift Fvertical_motion's end position by 1 line in diagram 1, but
not in diagram 2.

-- 
Alan Mackenzie (Nuremberg, Germany).