Can't track flow of characters in from Input Method Editor

Richard Wordingham richard.wordingham at
Thu Oct 8 15:45:34 PDT 2015

On Thu, 08 Oct 2015 10:18:15 +0100
Caolán McNamara <caolanm at> wrote:

> On Thu, 2015-10-08 at 08:52 +0100, Richard Wordingham wrote:
> > The intent of the call is to delete one Unicode character;

On reading the GTK documentation, it is clear that the arguments are
in terms of Unicode characters, and not UTF-16 code units. 

> I imagine you need to change signalIMDeleteSurrounding where we have
> nDeletePos = nPosition + offset and
> nDeleteEnd = nDeletePos + nchars
> and instead of adding "offset" and adding "nchars" you need to call
> getText on xText to get the string, then use
> OUString::iterateCodePoints to count forward from nPosition by
> "offset" IM codepoints to get the utf-16 offset for LibreOffice, and
> similarly iterateCodePoints by IM nchars to get the LibreOffice
> utf-16 nchars to delete.
> might suck rocks for performance.

I can't fathom how getText() works - obfuscation by abstraction!
However, as using OUString::iterateCodePoints would appear to involve,
at the very least, copying a long string, I have coded up a similar
function that works directly with the 'editable accessible' string
(and associated data).  I have added a patch to the bug report .


More information about the LibreOffice mailing list