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

[Eli Zaretskii]

> Date: Fri, 16 Oct 2015 15:19:36 +0000
> Cc: address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > > There must be some bidi compatible order operators which express
> > > "earlier than" etc.  I will be needing these.
> 
> > Define "earlier than".  Is that on screen, i.e. in the visual order,
> > or in the buffer, i.e. in the logical order, a.k.a. "the order of
> > buffer positions"?  These two orders are different for bidirectional
> > text.
> 
> I've no experience with bidi text, or even RTL text.  Could you cite me
> an appropriate bidi or RTL file I could play around with, even though I
> couldn't read it.  Would I need any special set up with (for example)
> fonts, or input methods?  In fact, before asking you to answer these I
> should read the fine manual first.

Just turn on the 'hebrew' input method and start typing.

> Coming back to the first application of "earlier than" in the function,
> it determines whether or not there is overlap between the first text line
> on the screen, and the text between PT and `it'.  At the moment, this
> check for overlap is done with
> 
>   if (beginning < L0_phys_EOL
>       && end >= ws)
> 
> I can't grasp why this comparison might fail under bidi - all four
> variables hold text positions.

With bidirectional text, the character position increases
non-monotonically with screen coordinates.  So the intersection of
buffer position doesn't necessarily mean there's intersection of
screen coordinates, and vice versa.

> What could go wrong with comparisons involving BOL positions?  Am I right
> in thinking that in an RTL line, the "beginning of the line", i.e. the
> character immediately following a linefeed, would be displayed at the
> right hand side of the window, and that subsequent characters would be
> displayed to the left of this?

No.

The issue here is not text being displayed starting from the right
window edge instead of the left edge.  The issue is text that includes
both left-to-right and right-to-left characters.  In this situation, a
character that follows a newline could be anywhere on the next screen
line, even at its end.

> I see that `it' movements from "left to right" are going to move to
> successively lower buffer positions, and this will give me trouble.

No, it's much worse: when it moves, the screen coordinates increase
monotonously, but buffer position does not.  The buffer position can
go up for a while, then jump a head many places and start moving down,
then jump again and go up, etc.  That's what I meant when I said the
buffer position changes non-linearly with screen position.

> > As long as you use functions that move the iterator, you cannot safely
> > assign one 'struct it' to another.  That's because the iterator object
> > has a (mostly invisible) companion -- the bidi cache, which must be in
> > sync with the contents of 'struct it'.
> 
> But surely each struct it has its own bidi cache, doesn't it?

No, there's only one cache.