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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Oct 19, 2015 at 10:27:55AM +0000, Alan Mackenzie wrote:
> On Sun, Oct 18, 2015 at 08:44:46PM +0300, Eli Zaretskii wrote:
> > > Date: Sun, 18 Oct 2015 15:00:52 +0000
> > > Cc: emacs-devel@gnu.org
> > > From: Alan Mackenzie <acm@muc.de>

> > > > Another idea: did you try augmenting the X coordinate of the iterator
> > > > after it gets back to point at the beginning of Fvertical_motion?
> > > > IOW, after this line:

> > > > 	move_it_to (&it,
> > > > 		    (!disp_string_at_start_p
> > > > 		     || FETCH_BYTE (IT_BYTEPOS (it)) == '\n')
> > > > 		    ? PT
> > > > 		    : PT - 1,
> > > > 		    -1, -1, -1, MOVE_TO_POS);

> > > > modify it.current_x such that it's relative to the "actual"
> > > > window-start.  Then let Fvertical_motion do its job as usual.  Did you
> > > > try that?

> > > No, I haven't.  But I don't think it could work.  After anchoring `it'
> > > at "actual" WS, it would have to move up or down.  Any time the iterator
> > > is moved to a previous line, it re-anchors itself at a previous _xdisp_
> > > BOL then moves forward, losing the relationship with WS.

> > > So this idea might work with nlines > 0, but couldn't work with nlines
> > > <= 0.

> > One bird at a time, okay?  Could you please see if this idea works
> > with nlines > 0?  If it does, it significantly simplifies the
> > solution, because we could do something very similar for moving
> > backward, i.e. apply the correction after each move to a previous
> > line.

> OK, I'll try that.  Just give me a bit of time (I'm not as fast at coding
> as some people).

I haven't managed to get anywhere with this.  The code in
Fvertical_motion is already quite complicated, due to the variable
it_overshoot_count, and the various things that make it necessary, like
`before-string' or `after-string' overlays with LFs in them.  If we add
in code to correct for "actual" WS into the melee, the code could not
help becoming even more difficult to understand.

What makes me less enthusiastic about the approach is that it only
covers one case, that with (nlines > 0) where point is already within
the first text line in the window (not before it).

I still feel that my approach, of analysing the buffer after
Fvertical_motion has moved the nlines and correcting it's position, is
the right one.  It separates this complexity from the rest of Fv_m.

I've spent some time looking at bidi.c and SAVE_IT, RESTORE_IT.  In
essence, IIUC, the bidi cache that SAVE_IT saves belongs conceptually to
a struct it, but is too big to be included in it.  It would be possible
to modify this cache mechanism so that several struct it's could use it
simultaneously, but this would make things more complicated, and/or
introduce opportunities for memory leaks and so on.  So ....

Would the following strategy for maybe_move_to_exact_bol work?
o - Execute SAVE_IT on *it just once, right at the start.
o - Calculate the target position using several struct it's, as
  currently coded, ignoring bidi aspects.
o - Execute RESTORE_IT on *it.
o - Move *it to our target position.
o - Set it->current_x and it->hpos to zero.

How about putting maybe_move_to_exact_bol into xdisp.c, allowing it to
use SAVE_IT and RESTORE_IT without exporting these two macros?  In fact,
why not put Fvertical_motion into xdisp.c, too?  It would appear to have
quite a lot to do with display, and not a lot to do with indentation.

Another point I'd appreciate clarification on.  Some while back, for
example, your mail of Fri, 16 Oct 2015 20:26:08 +0300, we were talking
about the order of screen positions varying non-linearly with buffer
positions.  Is it true that if a continuation line begins at buffer
position A, then for x < A, buffer position x will be displayed on a
previous line?  (And also for x > A, x will be displayed on this line or
a subsequent one?)

> > Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).