Where is the Documentation for VSCode's Debug Adapter and Protocol implementation?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- typescript, vscode
Línea de trabajo
Comienza con la Debugger Extension Guide, la DAP specification, la VS Code API Reference y VS Code Mock Debug; después, inspecciona los archivos referenciados debugProtocol.ts y loggingDebugSession.ts. Compara sus descripciones con las release notes de breakpointLocations y la discusión citada del issue. Se considera terminado cuando se añada contexto oficial que explique los propósitos de las capacidades, el comportamiento visible para el usuario y las opciones y el mecanismo de LoggingDebugSession.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I’ve been trying to work my way through Debugger Extension documentation to improve an existing debugger extension. My resources so far have been:
- Debugger Extension Guide
- Debug Adapter Protocol Overview
- Debug Adapter Protocol Specification
- VS Code API Reference
- VS Code Mock Debug
I would love to add "Documentation for VS Code's DAP Implementation" to that list, but I have unfortunately not been able to find it. The best I've found is using JSDoc-driven IntelliSense on this package, but that has been less helpful than expected.
When attempting to determine how to map DAP Capabilities to the debugger I'm integrating, it helps to have a good understanding of how VS Code is going to use a feature.
One good example would be the supportsBreakpointLocationRequest capability. Here is its JSDoc comment in its entirety:
The debug adapter supports the
breakpointLocationsrequest.
Okay... that sounds like a DAP reference. Let's look at what the specification has to say about BreakpointLocations Requests:
The
breakpointLocationsrequest returns all possible locations for source breakpoints in a given range.
At this point I'm still confused. Looking at the members of the related BreakpointLocationsArguments type provides a bit of insight, but it doesn't definitively help me understand what the purpose of this capability is...
A web search for related keywords finally turns up something helpful:
Finding possible breakpoints in a source range
The new
breakpointLocationsrequest can be used by a DAP client to find all possible breakpoint locations in a given source range. This can be used in the UI in order to improve the discoverability of "inline" ("column") breakpoints.
Ahh! This is how we enable column breakpoints! Got it! That helpful context was provided in VS Code release notes from September 2019...
Would it be possible to add this to some official documentation, whether that be in the DAP Specification or VS Code's specific implementation, or both?
Other examples that I've contended (or am still contending) with:
- The
supportsSetExpressioncapability. I found the necessary context in a previous GitHub Issue. - The
LoggingDebugSessionclass. This is the base class for the VS Code Mock Debug project'sMockDebugSessionclass. That project appears to be how Debug Extension architecture is currently communicated. There is no discussion about what options exist for base classes here and no documentation about whatLoggingDebugSessionprovides beyond its base class (yes logging, but via what mechanism exactly?). The only way to know is to look to the source code and learn it.
In general, I think the documentation for the DAP and VS Code's specific implementation thereof could be greatly enhanced by providing deeper context for features. As someone newly interfacing with the API and familiar with my own debugger's capabilities, it would make my life much easier to understand what end-user experience is enabled by a feature/capability; to understand the "why" behind an API, rather than just the "what".
- Lenguaje dominante
- HTML
- Estrellas
- 1.8k
- Forks
- 173
- Merge medio
- 7 d 7 h
- PR fusionados (30 d)
- 2
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/debug-adapter-protocol
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
microsoft/debug-adapter-protocol#633 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
microsoft/debug-adapter-protocol#599 · 8 reacciones ·
-
under-discussion
Dificultad 2/5 1-3 horas Aptitud para principiantes 48/100
microsoft/debug-adapter-protocol#596 · 9 comentarios ·
Todos los issues de microsoft/debug-adapter-protocol
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
siderolabs/terraform-provider-talos#414 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
openvinotoolkit/openvino_notebooks#3665 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
JuliaComputing/jh#63 · 1 comentario ·
-
namespace operations
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
EclipseFdn/open-vsx.org#13488 ·
Los mantenedores suelen responder en 2 días
-
/sdd:work workers create disposable resources (simulators, containers) with no cleanup ownerAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
joestump/claude-plugin-sdd#263 ·
Los mantenedores suelen responder en 1 día