Editing source while debugging

[Vladimir Prus]

On Sunday 31 December 2006 16:15, Jens Dagerbo wrote:
> 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. 

Yeah, I was thinking the other day that the right interface would be:

	class Mark {
	public:
                virtual QIcon getIcon() = 0;
		virtual ~Mark() {}
        };

or something like that, and make Kate operate with pointers to Mark. So that
if a mark is moved, KDevelop is told that a specific mark is moved.

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

Yep, looks complex but not sure what else we can do.

- Volodya