Allow diagnostics messages to have markdown (or formatted text) content

[mjbvz]

Feature request
Allow diagnostics to display formatted content. The specific request was to show part of a diagnostic message in bold.

A few potential options:

• Allow diagnostics to use markdown content
• Allow diagnostics to use formatted text
• Add an "important span" to diagnostic messages that lets us control the styling of the diagnostic.

(This request came out of the FB meeting)

[octref]

Also related: vuejs/vetur#849.

[ChuckJonas]

At the very least it would be helpful to have to ability to link them to an external url (EG: web resource explaining the cause of the problem)

[samrat-gavale]

Issue #74632 was marked as dupe of this issue. @sandy081 , @jrieken , @mjbvz - I hope the current feature request will be implemented in such a way which would allow the content of a problem list item to differ from content of the pop-up shown for it in the editor. Please see #74632 for details. Also, I would be happy to contribute PRs for implementing this.

[sandy081]

@samrat-gavale I do not think it is a good idea to show different data for the same diagnostic at different places. If we support markdown we have to think how we want to show it in problems view. We can render the markdown also in problems view given that tree supports dynamic height.

[glen-84]

#11847 might also be relevant.

[samrat-gavale]

@samrat-gavale I do not think it is a good idea to show different data for the same diagnostic at different places. If we support markdown we have to think how we want to show it in problems view. We can render the markdown also in problems view given that tree supports dynamic height.

@sandy081 - by different data, I didn't mean completely unrelated data. We want to show detailed information (e.g. markdown with links) in pop-up and a short, one line summary in problems list for a given diagnostic. Given the scenario that the opened folder may have large number of diagnostics, if we show same detailed information at both places, the problems list is going to bloat up making it difficult for users to quickly go through all the diagnostics in the problems list to choose the most impactful ones to act on.

[ShiningMassXAcc]

@sandy081 - To add to @samrat-gavale when you are in the problems list, the user is triaging through issues that apply to the entire workspace in a UI element that is ~1/5 the size of the app. Once the user finds an item of interest, they double click. The context has changed from the entire workspace to only a specific file, and a specific line of that file with the context of the rest of the code around it in a UI element that is ~3/5 the size of the app. I think it's appropriate for the information presented to similarly mirror that scope and allow a data provider to add more rich information in this pane, where the user has clearly drilled in.

We can actually do this today by leverage two different systems - and that is what we'd like to avoid hacking around (others on this thread could do a similar hack until this is resolved). We have the ability in VSCode to "setDecorations" that is unrelated to the problems list. As such, we create one issue in the problems list that has triage text for that quick summary view pan - and when the user selects, we use the decoration interface to provide a detailed popup on that line to further guide them. The UI is clunky here, because we technically have both the problems list and custom popup present on this line of code. We'd really prefer to just use problems list end to end. We can share screenshots or video if that helps.

[sandy081]

I got it, but I wonder how can such a Diagnostic model object will look like in the API? At present the model has message property which is a string and what is the proposal for the model to show markdown in the hover and show one line summary in the problems view?

[glen-84]

Perhaps a new property hoverContent (or editorTooltipContent), which has a value that defaults to the value of message.

[samrat-gavale]

What @glen-84 proposed above sounds like a agreeable solution. @sandy081, if that sounds reasonable, I can take a stab at the required changes.

[sandy081]

Introducing a new property makes sense to me, but might need a better naming.

/**
 * The human-readable message.
*/
message: string;

/**
 * The human-readable description.
*/
details|description: MarkdownString;

@jrieken What's your opinion?

[octref]

If message is what will stay in problems panel, I hope it can support links as well (if the current plan is to not add a specific link to the error code) for #11847.

For Problems View, can't we truncate the message to fit one line if it's longer than one line? The only thing that might cause problem is code block, and I think it's fine to convert them into plain, un-highlighted <code></code> inline blocks.

[razzeee]

It would be really really helpful to not only have working links in the problems panel, but also at least a second color. As there are some languages that highlight important parts of a problem description.

[samrat-gavale]

@sandy081, @jrieken, do you have any specific guidance in this? Adding a new property for hover content should allow different content between problems panel diagnostic and corresponding hover tool-tip. In addition to that, what API changes are needed to allow markdown in the problems panel?

[sandy081]

Better approach is to make message a string or markdown string type. Question with this approach is how to represent markdown string in problems view.

[jonlepage]

https://github.com/yoavbls/pretty-ts-errors 😁

[RobbyCBennett]

https://github.com/yoavbls/pretty-ts-errors 😁

This extension is a great solution for VS Code and TypeScript, but we should really fix this issue with the Language Server Protocol, so it's fixed for all languages.

By improving the LSP, we could also see the pretty errors with the command "Go to Next Problem" and maybe even in the Problems panel, instead of just the hover.

[Samuel-Therrien-Beslogic]

Copied from microsoft/vscode-eslint#1719:

I'd like custom error messages set in rules like no-restricted-syntax, no-restricted-globals, no-restricted-imports, @typescript-eslint/no-restricted-imports, etc. to support basic formatting. Namely to have clickable links and support backticks for code:

I'm not sure if this is rather a core ESLint issue, if so, please let me know and I'll re-open over there.

[RobbyCBennett]

Copied from microsoft/vscode-eslint#1719:

I'd like custom error messages set in rules like no-restricted-syntax, no-restricted-globals, no-restricted-imports, @typescript-eslint/no-restricted-imports, etc. to support basic formatting. Namely to have clickable links and support backticks for code:
I'm not sure if this is rather a core ESLint issue, if so, please let me know and I'll re-open over there.

It looks like @mui/icons-material/Icon is dynamic, so you would benefit greatly from the new field that we added to the upcoming LSP 3.18.0. It's called messageDetails and it should support formatting and show more details than the simple message field.

I think that ideally the user should be able to choose to enable/disable the messageDetails (dynamic data about the specific instance) and the codeDescription (static data about the diagnostic code). I don't think that these 2 fields will be particularly simple to add, as the diagnostic on hover and go-to next/previous diagnostic views are separate, yet they essentially show the same data.

If you want to implement it now to the hover, you could use vscode.languages.registerHoverProvider to show markdown on hovered diagnostics. However, I don't think that you can add markdown to the other view.

[oscklm]

Bumping this issue. Sadly this very much affects the usability of the popular "Pretty TypeScript Errors" extension, and makes it near unusable when long errors are displayed as the original typescript errors clutter the "mini problems view" and for now there seem to be no way to disable those.

See:
@https://github.com/yoavbls/pretty-ts-errors/issues/3

[starball5]

Related to #100742 on Stack Overflow: How to pretty print clean TypeScript errors in VS Code?

[LukeberryPi]

bump! until this is solved, pretty ts errors is useless, unfortunately! see yoavbls/pretty-ts-errors#3

[razzeee]

bump! until this is solved, pretty ts errors is useless, unfortunately! see yoavbls/pretty-ts-errors#3

That's just not correct, and therefor off topic. Been using it for years and can assure you that it's not useless.

[16bit-ykiko]

Is there any progress? I found LSP Specification has already supported markdown string as diagnostic text, see Change the type of Diagnostic.message to MarkedString.

[MentalGear]

it's frankly unbelievable that MS would ship a product like this with such unreadable TS lint errors, when TS is also a MS product.

[pefribeiro]

Sadly, +6 years and running since the issue was opened. Someone has kindly contributed code already, which is waiting for a merge. Equally sad that the atom editor had support for this, but was conveniently killed by GitHub :-( Perhaps ping @jrieken ?