In Interpreted Mode, when enter long strings, such as ofile.write (" 
this is a long string...") or print ("this is a long string..."), the 
keyboard entry is delayed - sometimes for 20+ seconds. If one completes 
the string (typing blindly as not text is visible) and keys the 
closing ')', or one moves the entire shell window, the missing text is 
dropped on the entry line and one can continue typing.
This occurs after about 25 characters of the string.

(pyJohn)... additional information since this is a performance issue: 
Lenovo s10; Win XP; 1GB; Intel Atom 1.66 Mhz

I think this is a duplicate of issue 1529353.

Not issue 1529353.  Edit window stops updating after about 60 
keystrokes when a tooltip window is active.

1. Strings not necessary.  Only occurs when a tooltip is active.  For 
example, if rz is undefined, entering rz( followed by a long key 
sequence won't raise the bug.

2. When the tooltip window closes, the hidden keystrokes appear.  This 
can be triggered by moving the edit window or clicking somewhere. Once 
the tooltip window has closed, things act normally again.

3. Remarkably, one can autorepeat, say, five lines of 'i' with no 
problem.  Then enter another 50 - 60 'i' individually, and the bug 
exhibits.  I thought that typematic processing took place at the 
keyboard driver level, so that Tk would get passed the equivalent of 
single keystrokes.

This bug would be annnoying when entering long parameter tuples, e.g. 
when doing GUI coding.

I'm running Tk 8.5 on WinXP at the moment.   I'm guessing that this is 
a Tk bug.

As a workaround, if you need the tooltip, select Edit / Show Calltip 
from the menu or use the hotkey to 'reopen' the tooltip.  That will get 
you another 60 characters.  Otherwise, just hit esc to close the 
tooltip and your keystrokes will appear.

Occurs with and w/o the subprocess, but sooner (fewer char) with the 
subprocess.

If the MultiCall wrapper on the EditorWindow Text widget is disabled, 
the bug disappears.

Bug exhibits on Linux with Tk 8.4, but requires a couple hundred 
characters to show up.  Also goes away if MultiCall is disabled.

I've uploaded a patch to solve the problem.

In CallTipWindow.py, the showtip function binds key releases and button
releases to the checkhide_event function. The checkhide_event function
creates a .after callback to itself whenever it's called. Each key
release adds to a cascade of calls to checkhide_event which results in
Tk slowing down.

When checkhide_event is called from .after, the "event" argument takes
its default of None. Only then should a new .after call be made.

Attached is a patch against 3.2.2 which does proper after_cancel calls on the after calls to checkhide_event.

I can fairly easily reproduce the hang on a current OS X system and the latest patch appears to solve the problem.  Looks good to me.