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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 16 Oct 2015 20:12:38 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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
> 
> >   . 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?

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