-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Breakpoints in debug lost if line is inserted; IDLE #58313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
My environment is Windows XP, using IDLE and Python 2.7 distribution. Open an IDLE Python shell. Open the file with three lines in it, 1,2 and 3. In IDLE, Set Breakpoint on Line 2. In Shell, set Debug. In IDLE, select run. In the Debug window, click Go. Run stops at line 2, displayed in Debug. Click Quit. Edit the file, inserting a line 0, like: print "this is line 0". Save the file Run again, Go in Debug. The breakpoint has disappeared and the debugger does not stop on line 2 (now the third line). It doesn't stop anywhere. Delete line 0, and set breakpoint on line 2 again. At the end of the file, insert a line 4, such as: print "this is line 4". Run again, Go in Debug. The breakpoint is preserved, and the debugger stops at line 2. This is inconsistent behavior. I expect that a breakpoint will not disappear, and that it will always point to the same line, moving down when the line moves down. The breakpoint should move up if the line it refers to moves up. |
The ColorDelegator is responsible for providing the coloring for the BREAK tag which is used to mark breakpoints. When recoloring, the BREAK tag may be removed (find self.tag_remove in recolorize_main). This is precisely why the breakpoints disappear. On 2.7, you can use Control-/ to toggle the ColorDelegator. Doing so eliminates the behavior you describe. On 3.x, Control-/ is broken due to two ColorDelegators being loaded. See bpo-13495. A possible solution would be to separate the BREAK tags from the color delegator since these tags ought to be part of the debugging code only. |
New changeset 76ca8569a04c by Terry Jan Reedy in branch '2.7': New changeset d775fa9a9767 by Terry Jan Reedy in branch '3.4': |
I moved the BREAK tag configuration to PyShell.PyShellEditorWindow, which adds breakpoint support by subclassing EditorWindow. I wrapped the code in a function so we can also unconfig BREAK text colorizing. This might be desired when colored line numbers indicating breakpoints are added. |
Not sure if this consequence of the commit is intended behavior, but still placing it here. In any file, set a breakpoint on any line. Pressing <Enter> key anywhere after the first character, will create a new breakpoint in the next line. These lines will also get saved to the .idlerc/breakpoints.lst file. This is mostly(99.9%) Tk behavior. |
On 8/9/2014 10:13 AM, Saimadhav Heblikar wrote:
It is.
Pressing any normal key within a tagged slice inserts the corresponding A BREAK tag on line n encompasses one complete line, including terminal <BREAK>This is something. This is something else Insert \n after 'some' and we have <BREAK>This is some The tag now encompasses two complete lines (including, importantly, two
PyShellEditorWindow.store_file_breaks calls .update_breakpoints When I initially read the tag setting code, I wondered why include \n, <BREAK>This is something. This is something else</BREAK> Possible insertion of \n is an answer. The comment block for store_file_breaks addresses some of these issues, I have been thinking that PyShellEditorWindow, later renamed
# after applying either of your patches, at least locally. |
Forgot to mention: after inserting \n, the breakpoint tag can be cleared |
While working on bpo-22083, I noticed a few redundant comments. This patch removes them. |
New changeset 71fe5e336d5b by Terry Jan Reedy in branch '2.7': New changeset f33b4770a078 by Terry Jan Reedy in branch '3.4': New changeset 558d7fb48d74 by Terry Jan Reedy in branch 'default': |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: