Open penagos opened 4 years ago
In js-debug we get around this by sending a "continued" event followed immediately by a "paused" which causes VS Code to re-request the stack. An explicit way to do this would be more elegant.
In js-debug we get around this by sending a "continued" event followed immediately by a "paused" which causes VS Code to re-request the stack. An explicit way to do this would be more elegant.
To my knowledge however there is no way to indicate in the response to the StackTraceRequest which frame you want to be highlighted. I.e. by sending a continued/paused event pair to VSCode the stack should be identical on an up/down command -- just the active frame should be different.
@weinand is this feature on any upcoming milestones?
The purpose of the debug adapter protocol is to provide the data that the client needs for displaying the debugger's UI. DAP's purpose is not to control the debugger's UI, e.g. to determine the selection or what stack frame is active. The UI is implemented by the client in a way so that the end user is always in control.
If the debug console (and the underlying evaluate
DAP request) is used as an alternative means to drive the UI, then we would have to add a new concept to DAP.
Since this github issue has not sparked a lot of interest by other debug extension authors, I'm somewhat reluctant to assign it to an upcoming milestone.
While implementing DAP in gdb, the general concept of providing the user a way to send gdb CLI commands came up. This has a lot of implications, but one of them is handling up
/ down
, as in this ticket ... one idea here would be if a StackFrame
had selected?: bool
, indicating the selected frame. Then the adapter could send an invalidated
event for the stacks
area when the view changed (though a more fine-grained event would be nicer to avoid any re-fetching).
@weinand DAP has already the concept of events
, that can be sent by the server to warn the client about changes, why not use them? The stopped
event could be extended for frame-changes, with a selectedFrameID
info somewhere, no?
Under this definition of the debug adapter's purpose:
The purpose of the debug adapter protocol is to provide the data that the client needs for displaying the debugger's UI.
I believe that this feature request easily passes the test, particularly given the qualification that the data is for displaying the debugger's UI. To the extent that thread / frame selection plays a role for a given debugger, it (potentially) has a place in the DAP so defined.
The objection seems to come here:
The UI is implemented by the client in a way so that the end user is always in control.
Certainly in this case, where the goal is to reflect in the UI an action taken by the user through a different interface, the user is still in control. And I don't think that the objection carries weight in general, either. It would be a very strange debugger that changed important parameters unpredictably outside the user's control, so I don't think we need to worry too much about introducing user-hostile behavior by allowing debuggers to more accurately and completely report their state: a debugger that frequently does things a user doesn't want or can't understand won't find many users anyway. Instead, what this proposal prevents is desynchronizations that can make the graphical part of the debugger harder to use or less predictable / correct in its behavior.
It seems there is currently no event (or reverse request) defined in the DAP to inform clients of a change in the currently active stack frame. Allowing for such communication between the debugger and the client listening to DAP events will make it easier to keep debugger/IDE state in sync.
For example, in implementing a C++ DAP extension I would like to support GDB up/down commands in the Debug Console to change the currently active stack frame in the IDE. Today, it seems the only support the DAP has for rendering a change in the currently active stack frame is when the client initiates a
StackTraceRequest
or when a user clicks on a specific frame in the IDE.