Maintain expand/collapse state of items in the variables panel when stepping through code in debug mode #32
Comments
|
That's interesting that they said that - I am not sure what VS Code is keying off of in the UI. There is no expansion state maintained by the debug adapter, or communicated in the protocol. Things stay expanded as expected in Nuclide, so this must be an interaction with VS Code. One thought off the top of my head is the IDs of Scopes and Variables change with each ScopesResponse and VariablesResponse - maybe VS Code is tracking expansion state by object ID instead of path? |
|
Yeah the ID change is most likely causing it |
|
Let me see what I can do here... |
…ects per-request Summary: Variables returned to the client in a VariablesResponse that are of complex types (objects, arrays, vec's, maps, etc) are assigned a variableReference identifier as required by the debug adapter protocol, so that the client can request the object's children in a subsequent command. Currently, the debugger is returning a new, unique ID for each initial variablesRequest after the target thread steps. This requires less bookkeeping on the back-end, and also protects against certain races like a setVariable command that is processed asynchronously after a target request thread resumes or steps (in which case it may be impossible or unsafe to set the value of the object). While the debug adapter protocol doesn't specify any restrictions on the variableReferene being reused vs unique, in practice VS Code appears to be using this to remember which nodes in the Variables scope tree are expanded or collapsed. The current behavior results in nodes collapsing after each step, which is frustrating to a user trying to watch the values of a child member while stepping through a code block. This was surfaced as issue: slackhq/vscode-hack#32 **This does not repro on Nuclide, which uses a path to the variable instead of the variable's internal ID to maintain expanded/collapsed state between steps.** This diff modifies the back-end to re-use variablesReferences for the same object within the same request, even if the request has stepped. This only applies to complex objects. Simple values (ints, strings, etc) don't have children, and therefore can't be expanded in the UI, so this doesn't matter. The identitiy of the object is determined by the object's actual in-memory address within HHVM, which assures uniqueness. A new client preferences option was added to the launch+attach command, disableUniqueVarRef, that disables this new behavior if specified. Reviewed By: velocityboy Differential Revision: D10274418 fbshipit-source-id: 0e5d5d0fd2fe2d44c791e85aaa0c9ea33522bbb7
|
I pushed 83e2be29c4c771cf2ce5c158c2c43af1d518329d which will keep variableReference IDs for the same object stable within a request. I'm not certain how VS Code is tracking expansion state, but if it's by variableReference like we thought above, I think this should take care of it for you |
When using the debugger, everything in the variables panel gets collapsed on every step. This is especially annoying when trying to examine a nested structure.
I had initially thought this was a default VS Code behavior, but according to microsoft/vscode#32199 the state is determined by the debug server itself. Can dig bit deeper into this and see if this can be fixed in the extension debug adapter or by HHVM.
The text was updated successfully, but these errors were encountered: