<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Georgia">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:<br>
    </font><br>
    <font face="Georgia">zapSelectionWithCompositionWith: aString</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; "Deselect, and replace the selection text
      by aString.</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; &nbsp;Remember the resulting selectionInterval
      in UndoInterval and otherInterval.</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; &nbsp;Do not set up for undo."</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; | stream newString aText beforeChar |</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; wasComposition := false.</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; ((aString isEmpty or: [(beforeChar := self
      charBefore) isNil]) or: [</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; aString size = 1 and: [(Unicode
      isComposition: aString first) not]]) ifTrue: [</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ^ self zapSelectionWith: (Text
      string: aString emphasis: emphasisHere)].</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; stream := UnicodeCompositionStream on:
      (String new: 16).</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; stream nextPut: beforeChar.</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; stream nextPutAll: aString.</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; newString := stream contents.</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; aText := Text string: newString emphasis:
      emphasisHere.</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; self markBlock &lt; self pointBlock</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ifTrue: [self setMark: self markBlock
      stringIndex - 1]</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ifFalse: [self setPoint: self&nbsp;
      pointBlock stringIndex - 1].</font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; wasComposition := true. </font><br>
    <font face="Georgia">&nbsp;&nbsp;&nbsp; self zapSelectionWith: aText.</font><br>
    <font face="Georgia"><br>
      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 </font><br>
    <font face="Georgia">UnicodeCompositionStream takes over and that's
      when I see screwed up keyboard entry.<br>
      <br>
      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<br>
      <br>
      zapSelectionWithCompositionWith: aString<br>
      &nbsp;&nbsp;&nbsp; "Deselect, and replace the selection text by aString.<br>
      &nbsp;&nbsp;&nbsp; &nbsp;Remember the resulting selectionInterval in UndoInterval and
      otherInterval.<br>
      &nbsp;&nbsp;&nbsp; &nbsp;Do not set up for undo."<br>
      <br>
      &nbsp;&nbsp;&nbsp; ^ self zapSelectionWith: (Text string: aString emphasis:
      emphasisHere)<br>
      <br>
      So, regardless of whether the 2ms is good or not, it looks like
      there's a bug in this unicode addendum.<br>
      <br>
      Cheers,<br>
      Bob<br>
      <br>
      <br>
    </font>
    <div class="moz-cite-prefix">On 2/3/13 2:00 PM, David T. Lewis
      wrote:<br>
    </div>
    <blockquote cite="mid:20130203190001.GA7082@shell.msen.com"
      type="cite">
      <pre wrap="">On Sun, Feb 03, 2013 at 10:33:14AM +0100, St??phane Rollandin wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Also I found this on the web:
<a class="moz-txt-link-freetext" href="http://forum.world.st/Real-Slowdown-of-InputSensor-between-3-8-and-3-9-td62714.html">http://forum.world.st/Real-Slowdown-of-InputSensor-between-3-8-and-3-9-td62714.html</a>

from where it seems that the reason for the wait is related to system 
window panes resizing logic...
</pre>
      </blockquote>
      <pre wrap="">
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



</pre>
    </blockquote>
    <br>
  </body>
</html>