homepage

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.