Change the type of Diagnostic.message to MarkedString

[smarter]

Currently, diagnostic messages do not carry any formatting information, this forces clients to be conservative when displaying them, see microsoft/vscode#22239 and the proposed solution:

Going forward. Deprecate the current way diagnostics are rendered and make them work just like the regular hover: a Markdown string which defaults to a non-monospace font but still lets language feature providers open up monospace code blocks with triple back quotes.

[dbaeumer]

We could the same that we did for CompletionItems and make this a client capability.

[razzeee]

This is still something that would vastly improve the experience.

[michaelmesser]

Why was this added to on deck then moved to the backlog? Was there some issue? This combined with #1056 would be useful to the Idris 2 LSP.

[dbaeumer]

Wrongly assigned it to On Deck. As you can see changes happened the same day.

[michaelmesser]

Is this blocked because the VSCode API doesn't support markdown for diagnostic messages? Unfortunately, the last comment was in February.

[KamasamaK]

LSP is not solely based on VS Code. If you can get this implemented in another LSP client, that should be sufficient.

[dbaeumer]

There are already feature in LSP that aren't supported in VS Code. All that LSP is requiring that new feature (whether or not implemented in VS Code) need to be guarded by a capability.

[michaelmesser]

If I made this into a PR, would it be merged?

export interface PublishDiagnosticsClientCapabilities {
    ...
    /**
     * Client supports the follow content formats for the message
     * property. The order describes the preferred format of the client.
     */
    messageFormat?: MarkupKind[]
    ...
}

export interface Diagnostic {
    ...
    message: string | MarkupContent
    ...
}

[dbaeumer]

@michaelmesser yes, that goes into the right direction. But we need an implementation as well (can be in a non VS Code client). Otherwise we have specification that no one implements.

[michaelmesser]

Do clients normally merge PRs for features not in the spec? Is an unmerged PR to a client sufficient? Is just implementing it in an editor plugin that extends an existing client sufficient? Is a server implementation also needed?

[dbaeumer]

In VS Code Is usually do the following:

• do a proposed implementation which actually ships in a next version of the LSP VS Code libs
• do a proposed specification.
• wait a little to wait for feedback
• make both the implementation and specification final

Regarding the specific question: it is good enough if it ships in a beta version. However, an unmerged PR is too little. It might happen that the feature never makes it.