Stack paging should not be implemented with a click

[joaomoreno]

Testing #4819

There are very good building blocks in our code for us to implement this properly:

• https://github.com/Microsoft/vscode/blob/master/src/vs/base/common/paging.ts
• https://github.com/Microsoft/vscode/blob/master/src/vs/base/parts/quickopen/common/quickOpenPaging.ts

Just talk to me for tips.

[isidorn]

We have explicitly decided on the explicit action, if you have concerns please comment here
#4792

Thanks for offering tips though :)

[joaomoreno]

That explicit decision was taken based on the loading stack frames is expensive argument. What? The reason not to do lazy loading is because loading is slow? You are doing lazy loading, you're just implementing it with a very poor UI concept: an extra clickable list item.

The only thing that you are missing to implement nice paging, like we do with the extensions, is the total number of stack frames. And, surprise surprise, you do have it in the protocol and all adapters either could or do implement it.

@weinand I further suggest to make that totalFrames mandatory. I doubt any debug adapter wouldn't be able to fulfil that request. A stack trace's length is always at any debugger's fingertips.

[isidorn]

I am fine with experimenting with this. It sounds good to me.
@weinand let me know what you think, if making totalFrames mandatory is fine

[weinand]

There is a difference between explicit/voluntary lazy loading and implicit/involuntary lazy loading.
We've decided to use explicit/voluntary lazy loading because it gives the user explicit control when to load more frames. implicit/involuntary lazy loading would mean: if a user resizes the CALL STACK view to be large (or uses a big screen and VS Code in fullscreen mode), more than 20 frames will be loaded. If more frames are loaded automatically, it is more likely that node.js becomes unresponsive because one of those frames is too large. You can implement Joao suggestion but then we need an opt-out mechanism for adapters like node-debug.

We cannot change totalFrames (or any other attribute) to become mandatory without breaking all existing debugAdapters, so we need a 2.0 version of the debug protocol (which would mean you will have to support two versions). We can plan for this, but it is nothing that we will introduce lightly.

[isidorn]

If nodeDebug would opt out of this then I propose to push this to the backlog.

[isidorn]

Another issue with this idea is that it does not work nicely for multi-threaded applications

[weinand]

@isidorn another good point.

[vscodebot]

This issue has been closed because the feature it requests is not within the scope of the product. See also our issue reporting guidelines.

Happy Coding!