Terry J. Reedy <tjre...@udel.edu> added the comment:
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).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
