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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 27 Oct 2015 13:40:25 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> 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).

In that case, it probably means I will have to do this.  Please send
the smallest patch that allows window-start to be where you want it,
and doesn't involve vertical-motion, together with some simple test
case to show what doesn't work in the unmodified vertical-motion.  I
will then come up with a fix for that function.

> 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 don't want to separate it, because vertical-motion already does
almost everything you need, AFAICT.  What you suggest would mean
significant duplication of code that is already quite tricky.  (Please
note that you for now tried to handle only the relatively simple case
of screen lines produced entirely from buffer text, no display or
overlay strings, no images, no display tables, no composed characters.
Most of the hair in vertical-motion's code is because of these use
cases.)

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

Not only is it big (and theoretically can be as big as the largest
buffer Emacs can support), its size is not fixed: while the display
engine iterates through buffer text, it constantly enlarges and
shrinks the cache as needed (assuming there's bidirectional text; if
not, the cache is always exactly 1 or 2 slots long).  So it cannot be
part of the it structure.

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

No, you cannot ignore bidi aspects.  The move_it_* functions work in
visual order, not in logical order.  So the bidi aspects are
inherently part of your use of those functions.

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

That's OK (assuming we need that function -- it looks too large for
such a simple job).  But that is a relatively minor problem.

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

I don't like moving such important functions between files, it
complicates forensics ("git annotate" etc.).  We have functions
elsewhere that use xdisp.c functionality, so it's not like indent.c is
the only one.

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

By "continuation line" do you mean the 2nd, 3rd, etc. screen line of a
long physical line?  If so, the answer is NO, not in general (although
in practice it's almost always like you describe, even when bidi text
is in the buffer).

> (And also for x > A, x will be displayed on this line or a
> subsequent one?)

Also no.

IOW, the visual order is non-linear both in X and in Y directions.