Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A way to trigger user-visible error/warning/info pop-up outside of an ErrorResponse #111718

Closed
polinasok opened this issue Dec 2, 2020 · 1 comment
Assignees
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues

Comments

@polinasok
Copy link

When we get an error while responding to a request, we can return an ErrorResponse and set showUser to get a very visible error pop-up.
image

Sending an ErrorResponse not tied to a request (e.g. a dup of the most recent response) is ignored (golang/vscode-go#182). OutputEvents let us write to the DEBUG CONSOLE and have a different colors depending on our choice of category ("stdout", "stderr", etc). Except, these kind of message tend to get overlooked in the ocean of logging and other output, especially if otherwise things look normal (e.g. microsoft/vscode-go#2783). In other cases, we need to communicate a user-visible message/warning while also sending a successful response (e.g. golang/vscode-go#787, where a next request gets cancelled by user request for a breakpoint, so we want to send a successful breakpoint response while also explaining the user that their action cancelled the pending next request).

If this requires a DAP spec change (as opposed to using a special category string with an OutputEvent or allowing orphaned ErrorResponses), I am happy to file an issue there as well.

@weinand weinand added the debug Debug viewlet, configurations, breakpoints, adapter issues label Oct 12, 2021
@weinand
Copy link
Contributor

weinand commented Oct 12, 2021

In general we are reluctant to support anything in DAP that "drives the UI" since only the client owns the UI and "drives" it.
So out-of-context notifications is not something we want to support easily...

But here are two suggestions:

  • create a DAP feature request where we can start a discussion about this independent from VS Code.
  • try to solve the problem in your extension code: your extension can make assumptions about the VS Code debugger UI and there is enough UI API to do whatever you want.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues
Projects
None yet
Development

No branches or pull requests

2 participants