On Jan 25, 3:02 pm, "Edward K. Ream" <[email protected]> wrote:
> > I don't think it's a "getting the encoding right at read time" issue.
>
> Neither do I. It's a problem with Leo's character-handling code.
The problem is easily stated: there is a confusion, perhaps within qt,
about what character indices mean for unicode characters requiring
more than one byte internally. This is a fertile source of bugs. This
might or might not be a Leo problem.
I have a feeling that this is at least partly a Qt problem. Some
examples:
Example 1. Suppose we select the following string: 연주기 This string
consists of 3 unicode characters. Typing any character works
properly, including backspace or return.
Example 2. Suppose we select the following string: वादक. This string
consists of 4 characters. Typing any character removes too much.
Here is leoQTextEditWidget.getSelectionRange:
def getSelectionRange(self,sort=True):
w = self.widget
tc = w.textCursor()
i,j = tc.selectionStart(),tc.selectionEnd()
g.trace(i,j)
return i,j
Traces show that j-i is 3 (correct) for example 1, but that j-i is 6
(2 too many) for example 2.
Leo dutifully records both i and j as the old selection range, so
Leo's undo command selects too much (but otherwise shows the correct
text) in example 2.
In short, it appears that Leo's w.getSelectionRange method is to
blame. This is not good news, because Leo is simply asking Qt for the
range of selected text. I added another trace that shows that
tc.selectedText() similarly miscounts the length of some unicode
strings.
It may be time to file a bug report.
Edward
--
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.
