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: https://github.com/vuejs/vetur/issues/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 https://github.com/microsoft/vscode/issues/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.

[samrat-gavale]

@sandy081, I am attempting a fix for part of this issue, specifically allowing the hover content to differ from what is shown in the problems pane. Here are the changes that I am envisioning:

1. Add a ‘details’ field to Diagnostic model which can store a markdown. This field would be separate from the ‘message’ field which stores only text.
2. Update the IMarker and IMarkerData interfaces to capture this new 'details' field when we generate a Marker from Diagnostic.
3. Update the computeSync() method in ModesContentComputer to return a MarkdownHover instead of MarkerHover.
4. In step 3 above, populate the MarkdownHover contents with Marker's details field if available, and if not, populate it with the message field.

Do these changes look reasonable? Also, since this would be an API change, I believe it would flow through propose API system (vscode.proposed.d.ts). But I am not very clear about the implementation. Do I define a new class, say Diagnostic2, in the vscode.proposed.d.ts which extends the Diagnostic class and use this new class wherever required, instead of the original Diagnostic class?

[razzeee]

So would these changes also touch the Problems view, as your mostly talking about hover? Would be a shame to exclude that.

[sandy081]

@samrat-gavale Not sure if it is a good idea to separate out. There is also need in Problems view to show links. If you want to proceed I would suggest to start with supporting markdown in message and see how you can render in Problems view. One idea would be is to render the markdown message when user expands the message just like expanding a multi-line message

[samrat-gavale]

@Razzeee - I am talking only about hover - adding an ability for it to differ from what is shown in problems pane. It seems difficult that I would be able to handle the problem pane changes to show markdown.

@sandy081 - as mentioned in previous comments, for various reasons, we need the content in the hover to be different than that in the problems pane. So I think we do need a separate field.

[razzeee]

In that case I'm not sure if this actually solves this issue. @mjbvz would know.

But my usecase and the reason I'm watching this issue is, that I need to highlight something in both, the problems panel and the hovers.

My compiler output is colored and right now we are loosing this vital information. With markdown, I would be able to just make these instances bold, which should work in most cases.

[sandy081]

as mentioned in previous comments, for various reasons, we need the content in the hover to be different than that in the problems pane.

What is the use case? Sorry if you would have mentioned it already.

[samrat-gavale]

@sandy081 see: https://github.com/microsoft/vscode/issues/54272#issuecomment-507353211 and https://github.com/microsoft/vscode/issues/54272#issuecomment-507749561

I had filed a separate issue #74632 for our requirement of allowing the problems pane content to differ from pop-up content, but was duped to current issue. See my comment about that https://github.com/microsoft/vscode/issues/54272#issuecomment-507341773 I can reopen that issue so as to keep the conversations separate.

[sandy081]

@samrat-gavale I see your point about making problems view simple and let the diagnostic hover in the editor to be rich. Given that rendering markdown in problems view is not trivial (not sure how feasible it is), I will bring this proposal (introduce new property in Diagnostics) with the team and get back to you.

At the same time I would also like to say this will take time (at least not till October milestone) as we have different plans.

Thanks

[octref]

When we add Markdown support for diagnostics messages, we can also fix a few UI inconsistencies:

• Messages are rendered in sans-serif in Panel -> Problems View, but monospace in Diagnostics Hover

• Plaintext diagnostics messages are rendered in monospace in Diagnostics Hover (editor font), while plaintext hover messages are rendered in sans-serif. This was #56862 and I folded it into here.

  

[samrat-gavale]

@sandy081 any updates about the progress on this? Was this discussed with the team?

[sandy081]

Planning to bring this up for December plan.

[octref]

If you want to proceed I would suggest to start with supporting markdown in message and see how you can render in Problems view.

IMO there can be an inline renderer for Problems Panel. Render everything beside link, italic and bold as plaintext. For example, such markdown would look like this in inline:

# foo
- [bar](https://www.google.com)
- baz

This error is an **important** one

# foo - bar - baz This error is an important one

Alternatively, take out the markdown constructs as well

foo bar baz This error is an important one

Faithful rendering isn't the point in Problems View. Having glance value of the error message and making errors searchable is enough.

[razzeee]

underline would also be nice

[yoshuawuyts]

In https://github.com/rust-analyzer/rust-analyzer/issues/4077 I filed an issue about rust-analyzer's highlighting functionality not being up to par with Rust's CLI output. They mentioned being blocked on this issue. I think having this functionality would be a great boon, not only for Rust but for other languages that have rich diagnostics as well.

Not being able to indent and not having bold text seem to be the two most important features missing currently.

Screenshots

Rust CLI output

The missing &mut in the type signature clearly stands out here.

VS Code problems panel

Spotting the missing &mut took me a good amount of searching, getting me out of my flow.

[razzeee]

@sandy081 were you able to bring this up for consideration? In my opinion it's the biggest missing piece for the language server experience right now.

[sandy081]

Not yet as I got engaged with other priorities.

[orta]

I'm trying to get a sense of whether this feature is blocked for someone else to implement. It looks like we're waiting on the diagnostics team deciding if the trade-off of having an API shape like:

{
  message: "Expected '123' got '456'",
  details: "Expected **'123'** got **'456'**"
}  

Where message is used in the problems view, and details is used in the hover is an acceptable API.

It doesn't look like we're too sold on details or description, could maybe messageExtended work?

[razzeee]

message should also be markdown, not sure if you meant that?

[orta]

My guess is probably not also, converting existing messages to be treated like markdown is probably going to make a bunch of extensions' outputs look weird.

[razzeee]

Well, you could opt in into it, via a different model.

[sangwoo-joh]

Is this feature still under construction?

[phord]

I am seeing some diagnostics rendered as Markdown and I don't like it. Is it because of this feature? Shouldn't be since this is still open, right?

Here's my example: The # is interpreted as a <h1> tag here when it is meant to be "number"

[michaelmesser]

@phord I think that is hover which is different than diagnostics. It might be a bug in the language server.

[michaelmesser]

This issue is in the top 5% of open issues by votes. It is also the 6th highest voted issue in the LSP repo. Will this be brought up for consideration? It would also be nice to be able have semantic tokens in diagnostic messages.

[MetalSlime0]

Is there a way to vote to prioritize this request? I'd really like to use markup in diagnostics for my language.

[gjsjohnmurray]

@MetalSlime0 you should add your 👍 reaction to the first post, the one that created the issue. See https://github.com/microsoft/vscode/wiki/Issues-Triaging#up-voting-a-feature-request

[hyangah]

I am coming from https://github.com/microsoft/vscode/issues/74632. What we want is to allow the markdown and rich display in the hover message. Not the full markdown content support for messages displayed in the PROBLEMS panel. Concise, simple text is preferred for the PROBLEMS panel IMO (if the concern raised in https://github.com/microsoft/vscode/issues/54272#issuecomment-530974468 is still under investigation).

Another related open issue is https://github.com/microsoft/vscode/issues/54503 - I think, if markdown content specialized for hover is allowed and handled like in usual Hover support, many users can avoid hitting the issue.

The first post which was open in 2018 and diagnostic message handling had been evolved a lot (including link support, etc). I find the first post does not exactly describe the feature we need - can we update the first post for better discoverability?

And what is the currently available workaround? I was considering to utilize the Hover but I am afraid presenting the same issue twice in the editor space (one by the diagnostic's hover, one by my own hover) doesn't seem like a good idea.

[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 https://github.com/microsoft/vscode-eslint/issues/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 https://github.com/microsoft/vscode/issues/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 https://github.com/yoavbls/pretty-ts-errors/issues/3

[razzeee]

bump! until this is solved, pretty ts errors is useless, unfortunately! see https://github.com/yoavbls/pretty-ts-errors/issues/3

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