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

New OutputEvent category for highly visible output messages #218

Closed
polinasok opened this issue Oct 13, 2021 · 3 comments
Closed

New OutputEvent category for highly visible output messages #218

polinasok opened this issue Oct 13, 2021 · 3 comments
Assignees
Labels
feature-request Request for new features or functionality
Milestone

Comments

@polinasok
Copy link
Contributor

According to the spec, there are now four categories:
category?: 'console' | 'stdout' | 'stderr' | 'telemetry' | string;

I don't know how other editors treat these, but in vscode console, stdout and stderr all go to the same place (Debug Console). And they are usually used for target's output as well as continuous logging from the debugger or client. That stream of messages can be a lot to process and critical things can go unnoticed. It would be quite useful if there was an additional category that received special emphasis and could be used for extra critical one-off messages that really need to stand out and not get overlooked by the user. Additional context is here: microsoft/vscode#111718.

@weinand weinand self-assigned this Oct 19, 2021
@weinand weinand added the feature-request Request for new features or functionality label Oct 19, 2021
@weinand weinand added this to the November 2021 milestone Nov 3, 2021
@weinand
Copy link
Contributor

weinand commented Nov 15, 2021

I suggest to add a new value important to the Output event's category property.
(if you have suggestions for a better name, please let me know)

Its description text will explain that this is a "hint" for the client to make the message highly visible, e.g. by using a presentation style that makes it stand out from other output debug console messages or by showing a popup notification.
If a client does not understand important, the value console is assumed.

Please note that this mechanism cannot be used to ask the user for input.

Here is the new important value embedded in the category property of the Output event:

/** The output category. If not specified or if the category is not understand by the client, 'console' is assumed.
    Values:
       'console': Show the output in the client's default message UI, e.g. a 'debug console'.
            This category should only be used for informational output from the debugger (as opposed to the debuggee).
       'important': A hint for the client to show the ouput in the client's UI for important and highly visible information,
            e.g. as a popup notification. This category should only be used for important messages from the debugger 
            (as opposed to the debuggee). Since this category value is a hint, clients might ignore the hint and assume
            the 'console' category.
       'stdout': Show the output as normal program output from the debuggee.
       'stderr': Show the output as error program output from the debuggee.
       'telemetry': Send the output to telemetry instead of showing it to the user.
       etc.
*/
category?: 'console' | 'important' | 'stdout' | 'stderr' | 'telemetry' | string;

@polinasok what do you think?

@weinand weinand added the under-discussion Issue is under discussion for relevance, priority, approach label Nov 15, 2021
@weinand
Copy link
Contributor

weinand commented Nov 23, 2021

Since there was no opposition, I'll release the proposal.

@weinand weinand removed the under-discussion Issue is under discussion for relevance, priority, approach label Nov 23, 2021
@polinasok
Copy link
Contributor Author

Thank you for addressing this. Sounds good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality
Projects
None yet
Development

No branches or pull requests

2 participants