Editing Sinhala and Similar Scripts

[Richard Wordingham]

On Sun, 23 Mar 2014 22:46:49 +0000
Marc Durdin <marc at keyman.com> wrote:

> All the Keyman products -- on Windows, web, iOS and Android, as well
> as KMFL, which is a port of Keyman, work on the principle of
> modifying the text buffer directly.

I had been going to remark that they couldn't do that directly, but
further research showed that Text Services Framework and GTK+ both
allow it to be done in fact as opposed to merely in principle.  (Does
this mean that the Keyman substitution rules follow the principle of
canonical equivalence?)
 
> The most obvious backspace intelligence I've seen in use is around
> handling NFC vs NFD text.  It is confusing to the end user if
> backspace sometimes deletes a whole character + diacritic, and
> sometimes just the diacritic mark.  For example, Vietnamese text has
> suffered from this issue with the varying composition schemes we've
> seen enforced by limited input methods.

However, with Keyman and KMFL there are fallbacks for when the text
buffer is not accessible. e.g. when using X and presumably when using a
Windows program that does not use the Text Services Framework. Version
1.07 of the interface between ibus and KMFL shows that a backspace
character generated by the input method (as opposed to simply passed on
from the keyboard) is intended to delete exactly one character.  It
seems to me that at least where fallbacks are used, the backing store
that KMFL wishes to delete must be in the state in which KMFL placed it
- intervening normalisation will corrupt the input.  Is there an
explicit statement of this anywhere?

When using X, it is possible to tell a backspace generated by the 'Input
Method' from one simply generated by the keyboard; the keycode is 0 in
the former case but not the latter.

Richard.