================
@@ -118,8 +138,8 @@ class Document {
BulletList &addBulletList();
/// Doesn't contain any trailing newlines.
- /// We try to make the markdown human-readable, e.g. avoid extra escaping.
- /// At least one client (coc.nvim) displays the markdown verbatim!
----------------
tcottin wrote:
This patch changes 2 things for markdown:
- The documentation string is taken as is without escaping anything (except for
html tags and entity references)
- Paragraphs are separated with an empty line
My idea was to let the client handle the markdown rendering completely.
Therefore no escaping is needed and even false because if markdown annotations
are escaped, the client will not render it as expected.
The same for the empty line between paragraphs: this is how paragraphs are
separated in markdown.
I think it is save to assume that the client can handle unescaped markdown.
According to the [LSP
specification](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#markupContent),
if a clients capability is specifying `'markdown'` as `MarkupKind` for it
`MarkupContent`, the "content should follow the GitHub Flavored Markdown
Specification".
Now regarding `coc.nvim`: I dont use it and do not know the current behaviour.
Reading through e.g. clangd/coc-clangd#48 though, I understood that `coc.nvim`
requests `MarkupContent` with `'markdown'` but does not really render markdown.
Hence I would assume that in this case leaving out the escaping would result in
just not showing the escaping character.
Regarding the empty newlines between paragraphs I would also expect that the
empty line is just shown, creating better visual separations between paragraphs
But: @emaxx-google do you use `coc.nvim` and could you give this patch a try?
Maybe my assumptions are false and it causes issues I did not see yet.
Regarding the capabilities: I think currently there is only `'plaintext'` and
`'markdown'`.
Additionally there is the option to allow HTML tags when markdown is selected.
Other than that I dont know how we could handle this.
But I think we don't need to actually, because as stated above, if the client
specifies to support markdown, it should handle it correctly.
If it can't handle it, `'plaintext'` is always an option.
https://github.com/llvm/llvm-project/pull/140498
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
