I think this is fixed now in trunk (ST80-dtl.141). Indeed we were dealing
with two separate problems that conspired to make a real mess of keyboard
input in MVC. The wait2ms causes sluggish input, especially on a VM that
has poor delay time resolution. And the problem that you (Bob) identified
below caused cursor positioning to be completely wrong in the case where
the keyboard input was was two or more characters (because of the wait2ms
delay).

That second problem happened because the unicode conversion takes the
character prior to the selection pointer, which I think serves as an
indication that we are in the non-ascii world, and appends the new text
input through a UnicodeCompositionStream. Pointers are adjusted down
by one character to do this, then the resulting text is zapped back to
the paragraph. The bug was that the pointers needed to be moved forward
again by one character afterward the zapping in order to get back to
their correct position.

I am multi-lingual impaired, so if someone with a Japanese keyboard
could open a workspace in MVC and see if characters can be properly
entered, that would be good :)

Dave


On Thu, Feb 07, 2013 at 10:04:11PM -0500, Bob Arning wrote:
> 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
> >
> >
> >
> 

>