microsoft / microsoft/debug-adapter-protocol

Extend `StackFrame` to support longer description than `name`

Open
#433 2 comments 0 reactions 2 assignees View on GitHub

@connor4312 is already working on this.

Since Sep 15, 2023.

feature-request
Dominant language
HTML
Stars
1.8k
Forks
173
Avg merge
7d 7h
Merged PRs (30d)
2

Description

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 https://github.com/go-delve/delve/issues/3323#issuecomment-1499639519. 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 (https://github.com/microsoft/vscode/issues/193153). According to the conversation in https://github.com/microsoft/debug-adapter-protocol/issues/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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.