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.