Editing source while debugging

[Matt Rogers]

On Dec 31, 2006, at 7:15 AM, 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.
>

s/Hoepfully/Definately. Here's the deal though, we have to tell the  
KTextEditor developers what we need from the interface. So, email  
your stuff over to ktexteditor-devel so it can be discussed and or  
added. Patches work the best, of course.

If we need a change, let's get one, so at least we can get rid of all  
these problems that we have in KDev 3.x while we have the chance.

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


Matt