VSCode should only reset breakpoints after save when already debugging

[nojvek]

Here's a proposal for debugAdapters to support Edit on Idle, Edit and Continue scenarios.

Only reset the breakpoints after the file has been saved rather than every keystroke.

Notify the debugAdapter with an extra afterEdit:true arg in setBreakpoints

The debugAdapter can then asynchronously come back when it the new edited code is all mapped.

[isidorn]

Assigning first to @weinand to add protocol additions - if all looks good there then I can make changes on the vscode side.

[weinand]

@nojvek please correct me if I'm wrong but the purpose of the afterEdit flag is to help the adapter distinguish between the following two cases:

• user has modified breakpoints without editing the underlying source
• source was edited which results in new breakpoint locations

[nojvek]

Hi Andre,

That is true. It's basically signaling the debugAdapter that the sourcemaps
won't be accurate so wait till the script is parsed again.

The premise is this:

The v8 vm, chakra, clr and newer VMs can hot load source with their debug
api's. Having VScode hot load code is a very attractive feature.

On Friday, June 24, 2016, Andre Weinand notifications@github.com wrote:

@nojvek https://github.com/nojvek please correct me if I'm wrong but
the purpose of the afterEdit flag is to help the adapter distinguish
between the following two cases:

• user has modified breakpoints without editing the underlying source
• source was edited which results in new breakpoint locations

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8077 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AA-JVMB4s5JgvZs1CbjSCMBLveUAwBx7ks5qO7K1gaJpZM4I9XTk
.

[weinand]

@isidorn here are the details:

If breakpoints are changed and ...

• source is not dirty then a setBreakpoints request with the attribute sourceModified set to false is issued immediately.
• source is dirty, all breakpoint modifications are tracked but no setBreakpoints requests are issued until the next save of the source. In the meantime breakpoints are shown as unverified. After the save a single setBreakpoint request with the attribute sourceModified set to true is issued.

In both cases the result status returned from the setBreakpoints request is applied immediately.

[isidorn]

@weinand sounds good, assigning to me so I look into it on the vscode side

[isidorn]

@weinand just to clarify, if the auto save is turned on then the source is never dirty, sourceModified is false and requests are issued immedtly?
Also I do not see the sourceModified field added in our debugProtocol?

[weinand]

@isidorn even with auto save turned on there is a short period of time (500ms?) where the file is dirty and where breakpoints should not be updated. So I suggest that the two cases are not treated differently. Breakpoints are always updated after the next save.

I'll add the sourceModified in a moment...