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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Oct 16, 2015 at 09:23:10PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 16 Oct 2015 18:12:50 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > But why do you need to do that?  IOW, what problem does
> > > maybe_move_to_exact_bol solve, and how that problem is related to what
> > > Fvertical_motion does?

> > > Perhaps start by explaining what problems you discovered in
> > > Fvertical_motion that required you to make those changes.

> > Without maybe_move_to_exact_bol, vertical-motion, when it lands near
> > the top of the window, leaves the cursor not at column 0 on the screen.

> > So, for example, with point at C, unmodified (vertical-motion -1) takes
> > us to A2, when we want to go to L3.

> So all you need is make a correction after Fvertical_motion did its
> thing, is that right?

After Fvertical_motion has _almost_ done its thing.  (i.e., after it's
moved by rows, but before applying a column offset, should such have
been requested).

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

(Quick recap of the notation: WS is the "exact" window start, L1 is an
"exact" BOL.  B or A (here, B) is the "xdisp" window start, A is an
"xdisp" BOL.  C, C2, C3 are "common" BOLs.  ^ is point, "it" is
Fvertical_motion's first placement of `it', T is our target BOL.)

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.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).