|
From: | Daniel J Sebald |
Subject: | Re: Stepping into local functions no longer works |
Date: | Tue, 30 Apr 2013 02:59:51 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |