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.