On Jan 27, 2:53 pm, Terry Brown <[email protected]> wrote:
> > We are pretty much done, and pretty much stuck. There is, imo, a real and
> > severe bug with cursor.movePosition.
> I'm not convinced. Given the characters: > > a K b M c N d > > where a-d are
> cursor placements and K, M, and N are unicode characters, and K is one of the
> unicode-combining characters, qt will report positions n, n+2, n+3, and n+4
> for a,b,c, and d. But when you move through it with the cursor keys it only
> takes three key strokes, a->b, b->c, and c->d. So if cursor.movePosition is
> supposed to behave like the user pressing the keys, it's making sense.
Let me try to get this straight. Only 3 cursor movements are necessary
to step across all three characters, but when we are done we are at
position n+4. Right? How can this possibly be *not* a bug? If this is
in any sense correct, how is the cursor position useful?
My point is that only Qt should have to deal with the internals of
unicode, whether a character is ascii, unicode, unicode-combining,
whatever. If this "black box" condition is violated, the gory details
"leak" into the app. That simply cannot be correct. But this is all
theoretical, and I've said it before.
I believe I have convincing proof that there is a bug somewhere in Qt
related to indices. We can see this clearly as follows:
1. Select this text: वादक
2. Type any character, including a backspace. With tracing on in
onBodyChanged, the oldSel will be (n1,n2) where n2-n1 = 4. This is
*correct* by any reasonable interpretation of indices.
3. Do the undo command, with what I call the sel_hack enabled in
leoUndo.py.undo(). The effect of this is as follows:
- undoTyping sets
self.sel_i,self.sel_j = i,j = oldSel
That is, we do *not* call w.getSelectionRange. We are using the
previous values for selection range as returned by w.getSelectionRange
*before* the undo. As we have seen, the delta is 4.
- undo() restores the selection range using self.sel_i and
self.sel_j. Again, the delta is 4.
Bug! The text is correct, but the selection range is one too big.
This could be a Leo error only if the low-level methods
w.getSelectionRange and w.setSelectionRangeHelper in leoGui.py were
buggy. This certainly is possible, especially considering the fiddling
done in w.setSelectionRangeHelper. However, tracing shows that the
fiddling does nothing (as expected) in this case, and that once again
the delta is 4 and the "moveRight" code is being executed with k = 4:
cursor.setPosition(i)
cursor.movePosition(e.Right,e.KeepAnchor,k)
To summarize: w.setSelectionRangeHelper is asking for exactly the same
selection as originally returned by w.getSelectionRange, and yet the
result is different for exactly the same text.
This *is* a Qt bug.
Edward
P.S. Rev 2843 contains the traces. The next rev disables them.
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
