octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stepping into local functions no longer works


From: Daniel J Sebald
Subject: Re: Stepping into local functions no longer works
Date: Tue, 30 Apr 2013 13:17:25 -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 03:11 AM, John W. Eaton wrote:
On 04/30/2013 03:59 AM, Daniel J Sebald wrote:
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.

I can see some cases where it makes sense to try to preserve the
breakpoint locations, but I can imagine others where the behavior is
potentially surprising. So I think that attempting to restore breakpoint
locations should be optional.

I'm not thinking about changes to the file made by some other editor.

Suppose there is a block of text that has some breakpoints set and I
replace it with some new text. Why should there be breakpoints set
there? The new text might not even be code, it could just be blank lines
or comments. Or it could be code, but these are new lines that may not
be interesting to me as breakpoint locations.

Well, I agree with that. If a breakpoint line is deleted, it's associated breakpoint should be removed. QScintilla currently doesn't indicate such a thing. I consider that a bug and I've emailed the QScintilla discussion list on that. (Haven't heard anything yet.) They need a signal indicating that a marker line was deleted.


Or maybe you are only suggesting trying to keep the breakpoints set on
lines that are not modified, but only moved? Or only modified and not
deleted? But what's the difference, how can you tell a modified line is
still interesting as a breakpoint location?

QScintilla associates IDs with their markers. So if a marker is moved, it still can be tracked. Therefore there is a mapping between the original debugger line number and the modified line number. Shifting a breakpoint line number isn't a big problem.

If the user does a whole bunch of editing such that markers end up at a line s/he really doesn't have interest in anymore, that's what the "delete all breakpoints" button is for, I suppose.

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]