[issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default

[Tal Einat]

Tal Einat  added the comment:

See issue #37827 regarding handling of progress output, as written by 
tensorflow.keras for example.

--
versions: +Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default

[Tal Einat]

Tal Einat  added the comment:

See issue #37768 regarding opening of help(object) output in a separate window.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I presume you are proposing to wrap the site-added help with a function that 
would check object outputs and put them either in the shell unsqueezed or 
directly into a viewer.  Seems plausible.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default

[Tal Einat]

Tal Einat  added the comment:

Regarding help(), there's actually a comment in IDLE's code by KBK that it 
should be opened in a reader (this was before TextViewer was added).  IMO 
that's a much better approach for long help() outputs, and is simple to 
implement.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default

[Terry J. Reedy]

Terry J. Reedy  added the comment:

A4: Autosqueeze long lines output in chunks.  tensorflow.keras appears to do 
this.  See #37762.  Easy reproducer:

for i in range(1):
print('%6s' % i, end='')

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default

[Tal Einat]

Tal Einat  added the comment:

In my opinion, everything here is relatively minor compared to some other 
current issues with IDLE, e.g. some of those mentioned by Raymond Hettinger in 
his comments on #35196.

That being said, a few comments:

> E1. Add 'Expand' at the top of the context menu.  (I sometimes right click 
> instead of double-clicking the squeeze label.)  (And add 'Help' at the 
> bottom, to display an explanation of Squeezer.)

I agree. If you create an issue, I'll make a PR.

> E2. Add a hot key to expand when the text cursor is on the line with the 
> squeeze label.

This existed in previous versions of Squeezer, but I removed it to keep things 
simple. It can easily be added.

> U1. If the squeeze label is near the bottom of the window, only the top few 
> lines are made visible.

Scrolling the screen for the user should usually be avoided. With scrolling 
being easy these days (scroll wheels, native scrolling in touchpads, touch 
screens) I vote to leave this up to the user.

> U2. *Perhaps* we should put the text cursor at the beginning of the output, 
> instead of leaving it at the next prompt, so nagivation keys work.

This would be the case when done via keyboard as suggested in E2. I'm strongly 
against moving the cursor upon un-squeezing text in general.


Regarding A1-A3 and the rest, I fail to see the point, but have nothing 
constructive to say.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default

[Terry J. Reedy]

New submission from Terry J. Reedy :

This issue continues #35196, which fixed some bugs (inconsistencies) in 
auto-squeezing and sped the scan of output strings for possible auto-squeezing. 
 This issue has two parts:
1. Make unsqueezing faster and easier for the user.  Details discussed below.
2. Reconsider the parameters and protocol for auto-squeezing.
2a. Increase the default setting for the minimum number of number of lines to 
squeeze.  The best setting depends on the result of part 1.
2b. Other changes?

(Some of the work might be done on separate PRs on issues that are dependencies 
of this one.)

If users ask for a big blob of text, they presumably want to read at least some 
of it, usually from the beginning, and possibly scan up and down.  The most 
common example is output from help(object), defined in the pydoc and 
_sitebuiltins modules.

Help first computes a single output string, whether 2 lines (list.append), 600 
(itertools) or over 2 (tkinter).  For modules, one most likely want to see 
the module docstring.  Those for itertools are about 40 and 80 lines 
respectively and both list the functions/classes in the module.

With standard interactive python on a text terminal/console, help output is run 
through a pager.  If more than a full screen, output is paused with a prompt.  
I consider both 'more' on Windows and 'less' on Mac to be overall 
unsatisfactory, especially for naive beginners, and hope we can do overall 
better on IDLE.

On Windows, the prompt is "-- More --", with no hint of what to do.  One can 
experiment and discover that Enter means 'display one more line' and Space 
means 'display one more screenful'.  Or one can guess to enter "more /h" at a 
console command prompt.  Either way, paging a thousand times to get the entire 
output for tkinter is not practical.

As far as I can tell from the 'more /h' output, there is no 'dump remaining 
text' command other than 'p '.  What is worse, 
a Windows console only holds the last N lines displayed, where N defaults to 
300 and can be increased to at most . So scrolling back is limited.  This 
is terrible, especially at the default setting.

On Mac Terminal, the pager is 'less', the prompt is ':', Space and Enter do the 
same, scrolling is only partially possible and weird, P goes to the top, a 
number N after space goes down N lines, to an 'END' prompt. As near as I could 
discover, less refuses to exit until one hits 'q', at which point the help text 
disappears.  This is true even for the 2-line help for list.append.  Terrible.

On IDLE, without squeezer, the entire text is displayed followed by a fresh 
'enter code' prompt ('>>>').  However, for multi-screen text, the user 
immediately sees only the last lines, not the first.  This is bad, But at least 
there is a possibility of scrolling up and trying to find the beginning of the 
text, although this may take several seconds.

When squeezer unsqueezes, it makes the first line, not the last line, visible.  
For a long enough output string, the easier way to get to the first line to 
start reading, other than scrolling, is to squeeze and unsqueeze.  (This 
applies to open_file.read() also.)  Absent anything better, I now consider this 
the primary justification for auto-squeezing.

The following should make triggering expansion of a squeeze label easier and 
faster, in terms of user actions, regardless of how the  label came about.

E1. Add 'Expand' at the top of the context menu.  (I sometimes right click 
instead of double-clicking the squeeze label.)  (And add 'Help' at the bottom, 
to display an explanation of Squeezer.)

E2. Add a hot key to expand when the text cursor is on the line with the 
squeeze label.  After typing 'help(xyz)' and getting a squeeze label, I would 
prefer to hit   and perhaps use navigation keys instead of 
immediately having to grab the mouse.

E3. Stop the false (or at least out-dated) and confusing warning about many 
normal text lines causing problems.  The 2 lines of tkinter help is not an 
issue on either my years-old Windows desktop and slower years-old MacbookAir.  
I once printed over half a million lines , about 40 chars as I remember, on 
Windows IDLE without issue.

Long lines are a different issue.  'a'*1 is okay on Windows, but not on 
Mac.  On the latter, after unsqueezing, and scrolling down to the new prompt, 
trying to scroll back up results in the OS twirly pause icon for a few seconds. 
 The natureal response of adding more keys presses and mouse clicks trying to 
get a response probably made the experience worse.  This reminds me of my 
previous Windows machine a decade ago.  

A line length warning needs data both on the machine and the max lines of the 
text.  The latter might be gathered fast enough by checking line lengths in an 
after loop.


Once the text is expanded, it could be more immediately useful.

U1. If the squeeze label is near the bottom of the window, only the top few 
lines are made visible.