Stefan Schimanski wrote:
I don't like the reference to the BufferView cursor. cursorX gets a
arbitrary CursorSlice. It shouldn't depend on the cursor or some other
sideconditions.
This part I would tend to agree with, but I don't know what the correct
way to go about what we want to do is. Elazar has been asking about this
for a while already, and I don't think he's gotten a satisfactory
answer. Still, I agree that there probably is a better way...
If I understand correctly: cursorX is called for the cursor itself and
for the selection anchor. For the latter it makes a difference if the
cursor is inside the inset or outside. So somehow this fix looks like
being at the wrong position, i.e. it should be handled where the cursorX
for the selection is called. Otherwise in 6 months somebody else will
fall over another symptom fix without a real cure of the problem.
BTW, this fix has nothing whatever to do with a selection, so I'm not
sure I follow when you say that you think that this "should be handled
where the cursorX for the selection is called". It looks to me like this
fix *is* in the correct place.
Again, just to make sure we all understand the problem, and why this fix
fixes it:
ONM [LKJ IHG] FED CBA
Let's assume the above RTL paragraph. the [] signify an inset (a
footnote, say). Everything is in an RTL language, so we start on the
right, and each time we press the LEFT key we should move one position
to the left.
* Desired behavior:
When we're after (i.e., to the left of) F, pressing LEFT should move the
cursor (|) to this position:
ONM [LKJ IHG]| FED
* Actual behavior:
When we're after F, pressing LEFT moves the cursor to after the inset:
ONM |[LKJ IHG] FED
This is only a presentation problem. Pressing LEFT again moves the
cursor to the (RTL) beginning of the inset, as it should:
ONM [KLJ IHG|] FED
So the net effect of the current situation is that the cursor (again,
only presentation-wise) "jumps" to the "end" of the inset and then back
to the beginning. This is wrong.
The cause is what Elazar explained: the piece of code which he patched
is the one moving the cursor to the end of inset, by subtracting the
inset's width. This subtraction *should* take place inside the inset,
because inside it we want the cursor position to be calculated relative
to *left* edge of the inset; if inside we're still in RTL, this is
corrected internally, I guess. However, currently the subtraction is
also happening when we're "at" the inset, but not inside it, and that's
what's causing our problem.
The solution is to make sure that the subtraction takes place only if
we're inside the inset, but not when we're just "at" it. That's what the
proposed check achieves, we'd just like a more straightforward way to
perform this check.
> If I am wrong, correct me. I don't know the code with the selections
and
cursor placement too well yet.
Stefan
Thanks for your input!
Dov
