You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Extend StackFrame to support longer description than name #433
Many DAP clients use the values in name when rendering info about a stack frame.
interface StackFrame {
...
/**
* The name of the stack frame, typically a method name.
*/
name: string;
...
}
There is no length limit on name, but empirically we found long strings don't work well in some DAP clients (VS Code). See the screenshots included in go-delve/delve#3323 (comment). When the go debug adapter includes both package path (corresponding to "module" in other languages) and the method name in the name, it can produce a very long string.
StackFrameFormat was brought up while we were discussing how to surface both package and method name in the current VS Code UI (microsoft/vscode#193153). According to the conversation in #411, the debug adapter is responsible for formatting and producing the string based on StackFrameFormat. Now where should this potentially long formatted string go?
In the current spec, I cannot find any place other than name, and we are again back to the original problem. Some DAP clients cannot efficiently present a long stack frame name.
What do you think about having an optional longer description field?
I think VS Code can potentially present the longer description in tooltip.
Other DAP clients can also choose to select name and the new longer description based on the need, instead of arbitrarily hiding or truncating name.
The expectation of StackFrameFormat is definitely to put the result in name, so I don't think it makes sense for format to instead target a new field. But I could see the utility in a longer name that either doesn't pay attention to StackFrameFormat (probably the best option to me -- keep it simple) or has a new field in StackTraceArguments to control that format.
Activity
connor4312 commentedon Sep 15, 2023
The addition of an optional
description?: stringfield would make sense to me.gregg-miskelly commentedon Sep 18, 2023
The expectation of
StackFrameFormatis definitely to put the result inname, so I don't think it makes sense forformatto instead target a new field. But I could see the utility in a longer name that either doesn't pay attention toStackFrameFormat(probably the best option to me -- keep it simple) or has a new field inStackTraceArgumentsto control that format.