Well that's really interesting!

If I look at a Squeak 3.8 image, the MVC keyboard input works fine,
and the image contains neither the #zapSelectionWithCompositionWith:
nor the #wait2ms method.

If I look at a Squeak 3.9 image, the MVC keyboard entry is sluggish,
but does not have the problem of cursor jumping to the wrong place.
That image has #wait2ms, but not #zapSelectionWithCompositionWith:

So I am thinking that #wait2ms causes the sluggishness, and
#zapSelectionWithCompositionWith: is the source of the cursor
positioning problem. The two of them together resulted in the
completely broken keyboard entry in Squeak trunk MVC.

It seems likely that removal of wait2ms eliminates one problem
(sluggish keyboard entry) and masks the other problem with
#zapSelectionWithCompositionWith: which is still a bug of some
sort that needs to be fixed.

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
> >
> >
> >
> 

>