As always, Stefan, you are right :) .
I applied your patch (what threw me off was what you said about
including another patch --- which BTW, I would still commit separately).
Then it didn't compile --- there's a semicolon missing on line 347 of
the patch file, or at line 279(?) of bufferview_funcs.cpp.
But now it works, and like a charm: the selection patch you sent
yesterday works correctly in the case described below now. And also in
the case of the problem I reported yesterday in bugzilla of bug 3550. So
you're definitely doing something right ;) .
So all of these patches:
*) http://permalink.gmane.org/gmane.editors.lyx.devel/85956 (fix for bug
3754: cursor movement at RTL-LTR boundary)
*) http://permalink.gmane.org/gmane.editors.lyx.devel/86192 (this fix,
for issue (3) in bug 3551 --- except note that this also includes the
above patch, they should be separated, as that one is independent of
this one)
*) http://permalink.gmane.org/gmane.editors.lyx.devel/86105 (fix for bug
3550: selection in bidi)
are OK with me, and should be applied (in the above order).
Thanks for all your work on this, Stefan!
Dov
Dov Feldstern wrote:
Stefan Schimanski wrote:
As promised, here it is. This is the way to do it. It includes our
former patch for cursorLeft/Right to avoid boundary magic on
RTL-boundaries.
I don't understand what I'm supposed to apply this patch against.
@Dov: For the example where your patch was wrong, make a selection,
starting in an RTL paragraph, ending in a LTR paragraph. One of the
two sides will "see" the correct RTL setting by looking at the
buffer's cursor. The other one (the cursorX call for the anchor) will
also look there, but the information in the buffer's cursor has no
relation to the that position.
Stefan
I don't totally follow your explanation, but the fact is that the end
behavior is still correct (using Elazar's patch) in the case you
describe. OTOH, the selection patch from yesterday is *not* behaving
correctly.
To illustrate (with Elazar's patch for cursor movement, your patch from
yesterday for selection):
[IHG]FED
When pressing LEFT, cursor moves from after E -> after F -> Before G
(inside footnote). This is correct.
When selecting by SHIFT and pressing LEFT starting after D, selection
shows up as: "E" -> "[IHG]FE". But really, only "FE" is selected (you
can convince yourself of this by deleting). Continuing to select LEFT
again doesn't show any difference in the way the selection is, but the
cursor correctly moves to after the inset, and now everything really is
selected.
I haven't tried your new patch yet (see above), but if it's using the
same logic as the selection, then it may also be wrong... I'll try it
anyway if you'll explain what to apply it against...
Thanks!
Dov
