On Sun, 23 Mar 2014 22:46:49 +0000 Marc Durdin <[email protected]> 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. _______________________________________________ Unicode mailing list [email protected] http://unicode.org/mailman/listinfo/unicode
