Re: Stepping into local functions no longer works

[Daniel J Sebald]

On 04/30/2013 02:35 AM, John W. Eaton wrote:
> On 04/30/2013 03:14 AM, Daniel J Sebald wrote:
>
> > OK, I didn't know dbstop works that way. But I see now. Visually one can
> > tell the sub_function, but for the editor to figure that out isn't so
> > easy. Keep in mind the editor window contents could be modified. Maybe
> > the subfunction boundary is a case where an invisible marker could be
> > used.
>
> If the editor window contents are modified and the modified file is
> saved, the breakpoints will be cleared when it is parsed again.
>
> I know you want to try to do some tricks to save and restore breakpoints
> when the file changes, but I'm not convinced that it makes sense to
> attempt to do that. The contents of the file can change so that the new
> file is nothing like the old. Why should breakpoints be preserved in
> that case?

Because it is convenient to not have to go through a file and restore 
breakpoints.  A person could have a breakpoint at the top of a long file 
and one somewhere near the bottom.  Making a small change in a file 
somewhere otherwise means having to go back and place those breakpoints.

It's not really a trick.  It is simply a matter of keeping track of 
where the breakpoints are moving to, which is possible with the 
QScintilla setup.

If you are thinking of the case where the file changes outside the 
editor, the GUI will recognize that and inquire to reload the file. 
That is similar to opening the file in which case dbstatus should be 
enquired.  If there are no breakpoints set, then no red dots appear.  Is 
the scenario that someone is doing editing with some other editor and 
using the GUI editor merely for breakpoints?  I'd say figure out some 
way to place breakpoints in the other editor.

Dan