Editing source while debugging

[Jens Dagerbo]

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 
identity. 

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.


// jens