On 5/27/07, Martin Vermeer <[EMAIL PROTECTED]> wrote:
On Fri, May 25, 2007 at 01:01:54AM +0300, Elazar Leibovich wrote:
> This patch solves completely the issue of wrong display of the
> cursor
> when it is right in front of an RTL set.
> Normally when a cursor is in an inset in RTL mode, it's position
> is
> being calculated in the following manner. the '|' is the cursor,
> the
> [] is inset I, inside some outer inset A.
> WORD [ins|et]
> Lyx would inquire the X position of the cursor from the outer
> inset A,
> when in LTR mode it'll return the position which is in the
> leftmost
> part of the inset. Then it would inquire the relative position of
> the
> cursor from inner inset I. it would add the results and display
> the
> cursor in the result given by A+ the result given by B.
> In RTL paragraphs, A returns the position in the rightmost edge
> of the
> inset, and then it's adding to it the offset of the position
> given by
> I. A gets the position of the rightmost edge of inset I by
> substituting the inset's width from the position of the cursor
> before
> the inset. It "fixes" the cursor's position if it recognizes that
> the
> cursor is in the inset.
> Now the problem is, that the code that recognizes whether or not
> the
> cursor is in the inset is broken. It checks whether or not
> par_[sl.pos()] contains inset, and it is true even if the cursor
> is
> right before the inset and not in it! Like that:
> WORD |[inset]
> In that case the X coor "fix" would apply and the cursor would
> show up like that
> WORD [inset]|
> What I did is I added a better test for that. I tested whether or
> not
> the cursor slice (which I don't understand EXACTLY what it means,
> it's
> sort of pointer to a place in an inset) in the top of the cursor's
> stack (ie, the cursor slice the cursor is in now) is equal to the
> cursor slice we're getting as an input (which means the place we
> should calculate the coordinate of). Only if it is not equal (ie,
> the
> cursor is actually in the inset, and we need to calculate the
> coordinates of a place outside the inset) we will apply the fix.
> Dov - care to get another developer to agree and check it in?
Hmmm.... from reading the patch I get the opposite understanding
from what the comment appears to say. I believe the code is
correct though.
My understanding is, that the final cursor X position is obtained
by summing the contributions from all cursor slices from bottom
to top, representing a stack of recursively nested insets. For
every slice, if at the cursor position in this slice there is an
RTL-type inset, you must apply the "width correction" (because
conventionally we sum X contributions from the left), but _not
for the top/tip slice_ (because there are no further nested
insets at this point).
OK?
Seems correct to me.
- Martin
