Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#433 2 comentarios 0 reacciones 2 asignados Ver en GitHub

@connor4312 ya está trabajando en esto.

Desde el 15/9/2023.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.

Lenguaje dominante
HTML
Estrellas
1.8k
Forks
173
Merge medio
7 d 7 h
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/debug-adapter-protocol

Todos los issues de microsoft/debug-adapter-protocol

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.