Thanks, Cheryl, very helpful.  I have since played around with the patch.

Some context first.  I want to make improving Shell a major focus for a while.  Part of that is handling problematic output.  One solution is to remove it.  For instance, if I enter a statement with a name error, I would like to be able to, for instance, hit Alt-Cntl-Z ('Undo Output') and have the last prompt and output erased and the last statement made editable, with the cursor at the end.  
 
Boxing the output is an alternative to just getting rid of it.  Or in some cases, it might make it clearer that deletion is a good idea.  I think some detail's should be different for 'too long' versus 'too many'.

Initial comments using Cheryl's numbers.

1. I tried something more 'sensible': 'a'*10000 by itself and preceded by "for i in range(10): ".  I was surprised that this did not bog down my machine.  I will have to look at some old issues where I verified the problem.  (Perhaps something has improved?)  In any case, I think we should either refuse to expand something malignant or at least ask "Do you really want to kill IDLE by expanding this?"

2. I want IDLE to be more usable without a mouse, and usable with alternate mice.

3. I get the error when Notepad is opened.  For 'lots of lines', such as the 1000+ line output for help(tk.Text), the alternate window (or frame!) can and should be an IDLE edit or view window.  This will be important when IDLE becomes a tabbed application.  I would only want to use external software when a tk Text could not do the job.

8. "Enable editor = False" is needed to keep Squeezer off editor edit menus.  The extension config system has no way to differentiate between settings a user can change and those they should not.  As a feature, it would clearly be Shell only.  As I have said before, I want to move to graying-out menu items rather than inserting and deleting them.

4. I also want restrict new options to those really needed, as determined by experience.  Perhaps we can agree on a fixed cutoff.  Perhaps something like 'more than 100 lines or 5000 characters'.

9. Color option is not needed.  Use the tooltip color.  If we wanted, we could make it depend on whether the theme was light or dark.  If we did, this would be part of the Tooltip class, and not part of this issue.

5. I agree that the cursor should more.

6. Tooltips should go away when the mouse moves off the tool button, and it does.  Cheryl, not sure what you are saying here.  I should like to see the tip when moving the cursor with keys.  Perhaps the button should be replaced by tagged text.  One can click a tag as well as a button, and tab-bind and key press.

7. Making feature option changes take effect immediately was one of the improvements made with the conversion.

(new) 10. The button for 'a'*10000 says '(nn lines)'.  It should say '(10000 chars)' or '(1 line, 10000 chars)'.  The number of lines depends on the text width and changes as the width is changed.  I suspect the squeezer should be able to tell the difference, because when I prefixed 'for i in range(10):', I see 10 buttons with, for one width, '87 lines'.  After expand all and contract, to one button, I see '96 lines', which is 87 (for the first line) + 9 (for each of the rest).