Tal Einat <talei...@gmail.com> added the comment:
> 1. Yes. Always show. Fix delay at 80 until we decide on something better. Done. > 2. No. Max should be enough. Done. > I once printed over 500_000 short lines to see if scrolling remained > responsive. It did. I could have set min to 1_000_000 for that experiment. > Am I correct in presuming that only one block of output, between code imputs, > can be squeezed? Indeed. > 3. No, if not gone already. I don't want to proliferate keyboard shortcuts, > at least not until we get rid of some that must be nearly unused. Done. > 4. Maybe nnnn chars would be better. I'm still not sure, that just leads to very large numbers, where it's hard to judge what is excessive, e.g., "is 100,000 chars too much"? With lines, I feel it is more obvious: "1,000 lines? That's way too much!" > The viewer does not wrap. I think it should as there is now no way to see > entire line. Or it needs a scrollbar. Wrapping is the major cause of the text widget slowing down, which is why I've made the viewer support controlling the wrapping mode, and made Squeezer use no wrapping. I've now added a horizontal scrollbar, and also made the scrollbars in the viewer appear only when needed. Now, scrolling horizontally with very long lines is still slow, but at least just the viewer is affected. > Viewer is modal, but does it need to be? No, good catch, changed to non-modal. ---------- _______________________________________ 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
