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.