Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#433 2 commentaires 0 réactions 2 personnes assignées Voir sur GitHub

@connor4312 y travaille déjà.

Depuis le 15/9/2023.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

feature-request

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.

Langage dominant
HTML
Étoiles
1.8k
Forks
173
Merge moyen
7 j 7 h
PR mergées (30 j)
2

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/debug-adapter-protocol

Toutes les issues de microsoft/debug-adapter-protocol

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.