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

[Alan Mackenzie]

Hello, Eli.

On Fri, Oct 16, 2015 at 01:19:09PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 16 Oct 2015 09:55:35 +0000
> > Cc: address@hidden
> > From: Alan Mackenzie <address@hidden>

> > I think most of the time, I just need to assign one struct it to another.

> Let's postpone discussing this until we have a working code that
> doesn't break bidi.

Good idea!

[ .... ]

> > > Comparisons with == are OK.

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

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.

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?

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

[ .... ]

> 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?  That would
be the component bidi_it inside struct it?  Or am I missing something
here?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).