There's been something troubling me about this issue - why would 2ms 
mess up keyboard entry? Turns out the 2ms may not be the real problem, 
rather it helps get to the problem in this method from ParagraphEditor:

zapSelectionWithCompositionWith: aString
     "Deselect, and replace the selection text by aString.
      Remember the resulting selectionInterval in UndoInterval and 
otherInterval.
      Do not set up for undo."
     | stream newString aText beforeChar |
     wasComposition := false.
     ((aString isEmpty or: [(beforeChar := self charBefore) isNil]) or: [
         aString size = 1 and: [(Unicode isComposition: aString first) 
not]]) ifTrue: [
             ^ self zapSelectionWith: (Text string: aString emphasis: 
emphasisHere)].
     stream := UnicodeCompositionStream on: (String new: 16).
     stream nextPut: beforeChar.
     stream nextPutAll: aString.
     newString := stream contents.
     aText := Text string: newString emphasis: emphasisHere.
     self markBlock < self pointBlock
         ifTrue: [self setMark: self markBlock stringIndex - 1]
         ifFalse: [self setPoint: self pointBlock stringIndex - 1].
     wasComposition := true.
     self zapSelectionWith: aText.

if aString is more than 1 character long ( several 2ms delays might slow 
processing of characters to allow your fingers to get more into the 
typeAhead buffer), then this bit about
UnicodeCompositionStream takes over and that's when I see screwed up 
keyboard entry.

The test I used was simply repeatedly drumming my fingers over the 123 
keys in a workspace until the cursor jumps back a few chars and inserts 
somwhere other than the end of the workspace. Commenting out the wait2ms 
seems to correct this, but so, apparently, does reducing the method to

zapSelectionWithCompositionWith: aString
     "Deselect, and replace the selection text by aString.
      Remember the resulting selectionInterval in UndoInterval and 
otherInterval.
      Do not set up for undo."

     ^ self zapSelectionWith: (Text string: aString emphasis: emphasisHere)

So, regardless of whether the 2ms is good or not, it looks like there's 
a bug in this unicode addendum.

Cheers,
Bob


On 2/3/13 2:00 PM, David T. Lewis wrote:
> On Sun, Feb 03, 2013 at 10:33:14AM +0100, St??phane Rollandin wrote:
>> Also I found this on the web:
>> http://forum.world.st/Real-Slowdown-of-InputSensor-between-3-8-and-3-9-td62714.html
>>
>> from where it seems that the reason for the wait is related to system
>> window panes resizing logic...
> Stef,
>
> Wow, you just found the cause of our badly broken keyboard entry in MVC :)
>
> Since about Squeak 3.9, keyboard entry (especially on Linux) has had an
> odd latency delay that makes it all but unusable. I just tried commenting
> out the wait2ms, and suddenly keyboard entry is working again. I see no
> immediately obvious ill effects (cpu use does not go too high, and things
> generally still work fine).
>
> It seems that the delay was added back in about 2005, and very likely
> the changes to input events in the Squeak 3.9 time frame caused it to
> become a problem. I'm not sure the right way to fix this, but at least
> now we know the source of the problem.
>
> Thanks!
>
> Dave
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130207/ecb8a79f/attachment.htm