Editing source while debugging
jens.dagerbo at swipnet.se
Sun Dec 31 13:15:47 UTC 2006
On Sunday 31 December 2006 10:17, Vladimir Prus wrote:
> On Sunday 31 December 2006 03:29, Jens Dagerbo wrote:
> > > > Simple solution : leave it as it is and add a "code changed, do you
> > > > want to rebuild it?" when the user tries to resume the program beeing
> > > > debugged. This should be enouth of a warning that future breakpoints
> > > > might not be as accurate as possible.
> > >
> > > Then, we'd need a way to ask Kate not to move markers corresponding to
> > > breakpoints.
> > .. which we cannot do. KTE doesn't offer us this option. In fact, there
> > is no way we can differentiate between "The user added/removed a
> > breakpoint" (which we want to handle) and "The user is typing so the
> > markers are moving".
> But I hope we can ask the interfaces to change for KDE4, can we?
Hopefully, yeah. I think it's high time we tried to figure out what we need
from the markinterface from KDevelop.
I remember fighting with it when I wrote the bookmarks plugin, and I think
pretty much all problems comes down to: a marker has no user accessible
It would be very nice to have signals for markerRemoved(type),
markerAdded(type) and markerMoved() instead of just the simple "something
changed"-signal of today, but that information could be assembled on the user
side, if only the markers had identity.
> > The only thing I can see us realistically handling is my second option:
> > as soon as we detect typing in the active file when the debugger is
> > running, flush all its breakpoints - all bets are off, nothing we knew
> > about breakpoint positions is valid any longer.
> I suppose the provided we flush breakpoints only in gdb, and leave
> KDevelop's breakpoints alone, to be enabled on next debugger run, this
> might work.
Yeah, that's what I meant. :) Leave the editors markers alone, and recreate
the corresponding breakpoints on the next debugger run.
I guess we'd also need to remember which editors have been typed into and
disallow creating new breakpoints for them during the present debugger run.
More information about the KDevelop-devel