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 issue13495.

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':
Issue #14105: Stop removing breakpoints from Idle editors.
http://hg.python.org/cpython/rev/76ca8569a04c

New changeset d775fa9a9767 by Terry Jan Reedy in branch '3.4':
Issue #14105: Stop removing breakpoints from Idle editors.
http://hg.python.org/cpython/rev/d775fa9a9767

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:
>
> Saimadhav Heblikar added the comment:
>
> Not sure if this consequence of the commit is intended behavior,

It is.

> 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.

Pressing any normal key within a tagged slice inserts the corresponding 
character within the slice.  If the character happens to be \n, then the 
*one* slice encompasses one more line than it did before.

A BREAK tag on line n encompasses one complete line, including terminal 
\n. In slice terms, n.0:(n+1).0. An xml version might look like the 
following.

<BREAK>This is something. This is something else
</BREAK>

Insert \n after 'some' and we have

<BREAK>This is some
thing. This is something else
</BREAK>

The tag now encompasses two complete lines (including, importantly, two 
\ns). This is standard slice insertion behavior, which tk provides us. 
There is no new slice created.

> These lines will also get saved to the .idlerc/breakpoints.lst file.

PyShellEditorWindow.store_file_breaks calls .update_breakpoints
This sends text.tag_ranges("BREAK") to .ranges_to_linenumbers.
This specifically accounts for possible insertions with this loop for 
each tag range.
             while lineno < end:  # lineno initially start line
                 lines.append(lineno)
                 lineno += 1

When I initially read the tag setting code, I wondered why include \n, 
why not the following?

<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, 
and needs revision after the patch.

I have been thinking that PyShellEditorWindow, later renamed 
EditorWindow*, should be BreakpointEditorWindow and moved to debugger.py.#

* not to be confused with EditorWindow.EditorWindow, which should really 
be called BaseEditorWindow.

# after applying either of your patches, at least locally.

Forgot to mention: after inserting \n, the breakpoint tag can be cleared 
from either line independently. Tagging complete lines makes this easy. 
If a line is split into three and the middle line untagged, then the 
first and third are left separately tagged.

While working on issue22083, I noticed a few redundant comments. This patch removes them.

New changeset 71fe5e336d5b by Terry Jan Reedy in branch '2.7':
Issue #14105: Change comment to reflect fix.  Patch by Saimadhav Heblikar.
https://hg.python.org/cpython/rev/71fe5e336d5b

New changeset f33b4770a078 by Terry Jan Reedy in branch '3.4':
Issue #14105: Change comment to reflect fix.  Patch by Saimadhav Heblikar.
https://hg.python.org/cpython/rev/f33b4770a078

New changeset 558d7fb48d74 by Terry Jan Reedy in branch 'default':
Issue #14105: Merge with 3.4
https://hg.python.org/cpython/rev/558d7fb48d74