IDLE: Document tk's long line display limitation

[piotrsk]

BPO	28840
Nosy	@terryjreedy
Files	test.py: Example file to reproduce the issue

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/terryjreedy'
closed_at = None
created_at = <Date 2016-11-30.14:05:00.632>
labels = ['expert-IDLE', 'type-bug', '3.9']
title = "IDLE: Document tk's long line display limitation"
updated_at = <Date 2019-09-20.21:01:33.777>
user = 'https://bugs.python.org/piotrsk'

bugs.python.org fields:

activity = <Date 2019-09-20.21:01:33.777>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2016-11-30.14:05:00.632>
creator = 'piotr.sk'
dependencies = []
files = ['45705']
hgrepos = []
issue_num = 28840
keywords = []
message_count = 5.0
messages = ['282082', '282090', '282151', '282205', '352890']
nosy_count = 2.0
nosy_names = ['terry.reedy', 'piotr.sk']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue28840'
versions = ['Python 3.9']

[piotrsk]

IDLE included in Python 3.5.2 does not display correctly files with very long lines under Windows 7.

Attached example file does not show the third line correctly in Windows 7. These lines are part of a script that attempts to parse the messages.
Even though very long lines are not according to Python convention, they should be displayed correctly in the editor.
If Notepad does it correctly, I would assume IDLE can handle long lines too ;-)

[terryjreedy]

The lengths of the strings on the 3 lines are 644, 432, and 7728, as determined by adding 4th line to print them. In Win10, the editor window shows.

MESSAGE_1 = '02.... <to edge of window>
MESSAGE_2 = 'Ag.... <to edge of window>
MESSAGE_1 = 

The problem is the blank after '=' on line 3. If I put the cursor anywhere in the false blank, the line is filled in up to the cursor.

IDLE uses tkinter, which wraps tk. It is known that tk Text widgets do not handle long lines well. There is a previous issue (which I cannot find at the moment) about long lines (in Shell) making scrolling slow, Printing the third line in Shell, where long lines are wrapped, works.

I do not remember seeing this disappearing text problem before. Putting the string without blanks on a line by itself, the limit for correct behavior (the beginning of the line appears when the file is freshly loaded) is 2730 chars, including the quotes. I guess no one inclined to report a problem has tried anything longer before.

The need for such long literals in a code file is unusual, but definitely legitimate for testing. On stackoverflow, I constantly urge people to develop programs that read and parse data by putting sample data in the code file. (If not in a separate test file.) The workaround for literals over 2728 chars is to use Python's implicit string literal concatenation. For instance, "s = 'a' 'b' 'c'" results in "s == 'abc'". Using this, you could define your third string thusly:

m3 = (
'<first 2000 chars>'
'<next 2000 chars>'
'<next 2000 chars>'
'<last 1728 chars>'
) # 7728 chars

IDLE's column indicator makes this easy enough.

Not wrapping longs lines in the editor is intentional. So is not adding a horizontal scrollbar (not my decision). But if adding one solves this problem, I will reconsider. In the meanwhile, I will consider a new IDLE doc section "2.6 Tkinter limitations", which could also mention non-display of astral characters.

[piotrsk]

Thank you for explanation of the background problem. Updating documentation as you mention is a good next step.

Thanks as well for the proposed solution of splitting the input string, but as long as it is just a display issue, this is not needed for test strings.

On the other side, given tkinter limitations of displaying lines longer than 2728 characters, I propose following solution for IDLE:
If line to display is longer than 2728 characters (or whatever limit you set, let’s call it X), by default replace it with a line of X-3 initial characters followed by ”...” (internally, just for displaying purposes ;-)). As long as the current cursor position is not beyond X-3 column (99.99% of time working with the script), display the truncated line.

This will avoid confusion, as users will not see “empty”/”strange” lines browsing through the code and if someone really wants to manually edit character after the X-3 column, the display will be adapted accordingly.

Let me know what you think about it.

[terryjreedy]

Currently, the code displayed is the code saved and run when requested. Your idea would require that IDLE keep a 'true' copy of the code separate from the 'display' copy in the Text widget, with the two being kept in sync except in special situations such as super long lines. This would be an error prone process. It would require either having two text widgets, one displayed, one not, kept nearly in sync, or writing a Python equivalent of the non-display part of the text widget. Or the true copy could be a virtual copy represented by the edits required to restore the true copy from the display copy. Any of these would be tedious, error prone, and would make editing slower. I rejected the idea of making tabs visible with a special character for the same reason.

I looked at the tk Text doc to see if the line length limitation is mentioned. It is not that I could find ('2' occurs in the text, but no longer digit string). It might be Windows-specific. It is possible that there should be a new issue opened on the tcl/tk tracker, but more info should be collected first, to test on other OSes and directly with tcl/tk. I have more pressing issues to work on ;-).

While looking, I read the entry on peer text widgets, which allow multiple views of the *same* underlying text data. A peer can be restricted to a subset of lines but not part of a line or lines. (There can also be different default fonts and insert cursor positions.)

[terryjreedy]

IDLE Help's newish section "User Output in Shell" makes some mention of this but a bit more is still needed.

[terryjreedy]

On Windows with 3.9 to 3.11, I no longer see the disappearing line bug I verified in #73026 (comment). I am going to presume that the bug, possibly a regression, is fixed in current tk. (BPO user piotr.sk has no recorded github account.)