Debug locals variables display different on Legacy & Delve DAP adapters #1783
Replies: 4 comments
-
It looks like the setup on linux is using the new debug adapter, which uses Delve's native DAP implementation, while the windows setup is using the legacy adapter. These can be adjusted by setting the "debugAdapter" property in the launch configuration.
This is specific to the VS Code implementation, which auto expands the first scope only (see microsoft/vscode#93230). I think it would definitely be worth filing an issue with VS Code for this, otherwise the option that the Go extension has is to combine the scopes (which removes information) or reorder the scopes (which would result in Arguments not being expanded) |
Beta Was this translation helpful? Give feedback.
-
@mpetronic We encourage all users to use the new debug adapter, dlv-dap, so we can make it better and no longer a need the legacy adapter as a fallback. While we wait for vscode feature, how can we make your experience better? Option 1:
|
Beta Was this translation helpful? Give feedback.
-
I think it is fine to combine args and locals under one grouping. So my
vote would be for#2 option. I would say to keep globals under their own
grouping that is configurable and defaults to hidden. I don't see much use
for separating args under their own grouping because in almost every case I
want to see the arguments and the locals at the same time. Adding the
globals in to that group I think would clutter things up too much. I
appreciate you seeking my input on this.
…On Wed, Sep 22, 2021, 17:56 polinasok ***@***.***> wrote:
@mpetronic <https://github.com/mpetronic> We encourage all users to use
the new debug adapter, dlv-dap, so we can make it better and no longer a
need the legacy adapter as a fallback. While we wait for vscode feature,
how can we make your experience better? Option 1:
1. List Locals, Arguments, Globals in this order and then Locals will
be auto-expanded as the first listed scope.
2. Return both locals and arguments under locals without distinction
and have that scope auto-expanded. Is the distinction useful?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1783 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABSTHDXP2JFFLV5ISIU2IUDUDJGI5ANCNFSM5EHYVU4A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
Thanks @suzmue @polinasok and @mpetronic FYI I think this is a reasonable feature request and created a #1798 in the issue tracker. |
Beta Was this translation helpful? Give feedback.
-
I have the same vscode version installed on two workstations (versions below).
On the Linux one, when I debug and stop at a break point in a method in Go, I see a COLLPSED "Locals" drop down that I must click to expand. I need to ALWAYS click to expand every time I start a new debug session. Not a show stopper but I think the UI should remember my intentions and repeat for me. Also, my method args show up under an "Arguments" dropdown that is separate from the "Locals" variables dropdown.
However, when I do the exact same thing on Windows VSCode, the "Local" dropdown is NOT COLLAPSED as it automatically expands when the debug session restarts every time. This is the behavior that I believe should be the default. Also, ALL the variables (func args and locals) ALL show up under the ONE "Local" dropdown. Note that here it is called "Local" but on Linux it is called "Locals"
I surmise that, although I have the same version installed in both workstations, there are differences that are not aligned between the Windows and Linux builds of the app. One even says "Locals" while the other says "Local".
My question was how can I get the auto-expanding of local variables to work on Linux like it does on Windows thinking that there might be some configuration difference that I cannot find. If anyone knows of such a config, I would be grateful for the tip. Otherwise, do you suggest I open an issue to try to get these differences in behavior reconciled?
Thanks for any suggestions.
Version: 1.60.1 (user setup)
Commit: 83bd43bc519d15e50c4272c6cf5c1479df196a4d
Date: 2021-09-10T17:07:10.714Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19043
Version: 1.60.1
Commit: 83bd43bc519d15e50c4272c6cf5c1479df196a4d
Date: 2021-09-10T17:06:57.931Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 4.18.0-305.3.1.el8_4.x86_64
Beta Was this translation helpful? Give feedback.
All reactions