On Sat, Feb 9, 2013 at 12:29 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> Bob,
>
> I tried reverting zapSelectionWithCompositionWith: to its original
> implementation, and making the change that you suggest to readKeyboard.
> It works exactly as you describe, including when I type rapidly in an
> image with the wait2ms delay.
>
> I will make this update to Squeak trunk. To summarize the changes
> we will have at that point:
>
> 1) The wait2ms is removed
> 2) ParagraphEditor>>readKeyboard will always process one character at a time
> 3) No change to zapSelectionWithCompositionWith:
>
> Thanks very much for your help on this!

>From the author initials of #zapSelectionWithCompositionWith, I
thought that it does not have any bugs (hehe).  So, yes, handling
multiple strokes properly was the way to go.  Thank you for the fix!

The implementation was done primarily for the latin-1 input,
especially for the OLPC XO.  It went with the "dead key" to enter an
accented character.  So, you enter an accented latin character (say,
a-umlaut) by holding the alt-graphic key and hit the umlaut key. And
you can enter normal "a" next (say, 2 seconds later) and the VM and
the image receives 0x61 ("a") and 0x308 (combining diaeresis) at the
"same time".

In an application that favors the decomposed form would keep these two
code points and handles it, but Squeak (I think) favors the
pre-composed form and combine these two code points into one  ut.  The
other parts of Squeak cannot handle the decomposed form of code
sequence well, so we tried to make a composed form when possible in
Squeak.  (I.e., there are multiple possible code point sequence to
represent the same character in Unicode.  Anybody who thinks that
Unicode provides a uniform single representation is misled by them.)

When the image receives a sequance that it cannot compose, it gives up
and gives the sequence down stream (that is the logic in
#zapSelectionWithCompositionWith:  and UnicodeCompositionStream).  In
the end, it'd receive n characters at the same time, and need to spit
out m characters.

Inputting the asian languages is in a way less complicated.  The
front-end input method may generate multiple characters at once, but
they just have to be handles one by one properly.

--
-- Yoshiki