-
Notifications
You must be signed in to change notification settings - Fork 30.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support collapsing stack frames #50334
Comments
@isidorn we could collapse subsequent "uninteresting" stackframes into one expandable, right? |
@weinand yes, this could be easily done since we already use a tree for representing stack frames |
Then we should plan to implement this. |
Currently we have a The questions is how to name the expando element which would expand all subsequent deemphasized sources? Also note that these unimportant stack frames will be indented. Tree does not allow me to do variable indentation based on item type, only on item depth. fyi @roblourens |
Do we differentiate between different types of frames that might be collapsed separately? For example, if I have code that is "skipped by skipFiles" and code that is "skipped by smartStep", it might make sense for these to be marked differently so they would be collapsed as separate groups. I'm not sure what else debuggers are using presentationHint for. I can imagine it making sense to hide "smartStep" skipped frames entirely, since I never care about them, while "skipFiles" frames I may want to inspect but don't want them to be in my face. Maybe the DA should be able to label the collapsed group with a label that describes what's in it. And think about the case where the collapsed frames are at the top of the stack. e.g. I break on an exception in a "skipped" file. Chrome devtools will collapse the blackboxed frames at the top of the stack and focus the first non-blackboxed frame, and show the error at that non-blackboxed frame. I'm not sure whether I like that or not, typically in that case I end up expanding the frames and looking at the real line of code that errored. But it's worth thinking about different scenarios. |
In Dart/Flutter we use a few:
Probably we'd want to collapse them all together. Eg. imagine the stack looks like:
Having them collapse individually wouldn't make sense here (so doing it automatically by presentationHint would probably suck); though allowing the DA to assign a named group so they can control it might make sense.
I would love something like this. One of my gripes with the Dart debugger right now is that it breaks on exceptions inside code I've marked non-debuggable and I couldn't see an obvious way to jump back to the first debuggable source frame. |
I have pushed an initial version of this. Please try it out in tomorrow's insiders In short it will collapse all subsequent stack frames with source that has presentation hint Here's an example how it looks |
Awesome. Would be great to show the number of hidden frames (Show N more frames) |
Suggestion accepted. Great idea |
@isidorn This currently shows Edit: Looks like this comes from |
Also - it feels slightly strange to re-collapse as you're clicking on them. If you do want to navigate up the stack while debugging. I don't have a suggestion to fix that though; it'd need some other way to re-collapse 🤔 |
Also, is there a better description for what we can/should put in /** The (optional) origin of this source: possible values 'internal module', 'inlined content from source map', etc. */ But the The values I'd like to put in it are for SDK sources and for third party packages. |
origin is just a string shown in the UI but not interpreted by VS Code in any way. |
@weinand Great, thanks - I'll add suitable labels then :-) (though the |
@isidorn please fix the "undefined" label for October. |
Seems like this behaviour is specific to when a frame has no source. If the frame has source, it navigates there and leaves the section expanded. |
I have fixed the undefined label via 9f4969b |
Yeah I thought I couldn't recollapse them, is this a bug or how do I do that? |
You can not recolapse. This is a design decision made by @weinand and me since they collapse again after you step. |
Based on the above, it's not supposed to collapse. However it seems to be a bug that if you don't have source code for a frame (you return an error from |
Sometimes call stacks in the debugger contain a lot of frames from code that isn't the users (for example SDK code):
It would be good if we could somehow allow these to be collapsed so the user can focus on their own code, and only expand these if required.
Maybe it could even just be another presentationHint type for "unimportant" or "external" code, and VS Code can collapse consecutive frames with that hint, allowing them to be expanded by clicking?
The text was updated successfully, but these errors were encountered: