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