vscode: debug: option to disable the modal dialog on launch failure

This is a resurrection of the original feature request https://github.com/microsoft/vscode/issues/48606 (Previously discussed in https://github.com/microsoft/vscode-go/issues/1644 in microsoft/vscode-go, but we are still getting the same requests from users https://github.com/golang/vscode-go/issues/1375)

The feature request https://github.com/microsoft/vscode-go/issues/1644 filed in microsoft/vscode-go repo was rejected, I am afraid there was some misunderstanding during the discussion.

Go’s debug adapter&debugger (delve dap) does not only launch the debugee upon a launch request, but also performs the compile/build of the target binary. That is different from debug workflows of other languages that usually separate build steps from debug launch steps. When build fails, the adapter returns error for the launch request (we couldn’t build due to compiler errors so we couldn’t launch!), which results in the modal popup.

Revisiting @weinand’s original comment https://github.com/microsoft/vscode/issues/48606#issuecomment-384265967

I think there are two types of notifications:

  • expected (frequent) problems like compiler errors,
  • unexpected (rare) problems like a runtime error in a debugger or a non-existing variable in a launch config.

IMO the first type of problem should be addressed by the non-modal notification whereas the second type should result in a modal dialog because it is a fundamental problem that requires the users attention.

So, I’d say Go’s debug extension current behavior doesn’t match the expected UX.

Is there any workaround in DAP to implement this in vscode-go side? Separating the compile step from the launch as a pre-launch task is not ideal for Go since we depend on Delve’s decision on how to build the target with sufficient debug info.

Can we have an option to disable the modal dialog depending on the types of launch failures?

cc @polinasok @suzmue @isidorn

ps. I tried to use the showUser property (set to false), but that just controls the extra notification popup currently.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 19 (11 by maintainers)

Commits related to this issue

Most upvoted comments

@polinasok thanks for clarifying. I agree with you that the dust will settle eventually, and in the meantime the inconsistency which we might have is ok. So closing this as I plan no further changes here. Thanks

@polinasok thanks for trying it out. All good feedback. Let’s reopen so we try to address this.

  1. I see. We could only have this logic for launch requests, however that sounds not consistent. What do you propose? If the showUser is not defined the error will still be shown as before. So I do not understand how this can catch adapter implementors off guard. Can you clarify pease?
  2. When the dialog is shown we should not show the notification. Reason for this is that different code paths handle this and they are not in sync. I can look into this.

@isidorn ok, let’s do this.