helix: documentation shows markdown line breaks

[adiabatic]

The Feature Request

I pressed k (space, then k) in Helix to trigger its documentation-under-cursor feature. I got documentation for the p element, but for whatever reason the documentation window was extra-narrow and the hard-wrapped text got wrapped even tighter, leading to a very raggedy right edge.

I tried to recreate Helix’s indented help-text window in a minimal test case, but I couldn’t. Instead, I had to shrink the Terminal window to a ridiculously narrow column count to trigger the behavior:

Normally I wouldn’t put “Consider” at the beginning of a feature request, but the hard-wrapping might be the better idea in more-important/popular LSP-using setups, like, say, Visual Studio Code. I tried running the SuperHTML extension in VS Code, but I couldn’t get any kind of pop-up help in an unsaved HTML file to see what under-the-cursor documentation looks like there.

Would it be a good idea, on net, to not hard-wrap .desc in, say, src/html/elements/p.zig?

[kristoff-it]

The formally correct answer is that in Markdown a single newline does not constitute a break in the rendered output, meaning that in this case it's Helix that is rendering Markdown wrong. I believe VSCode doesn't suffer from that problem.

Note that the fact that this string is Markdown syntax is not just my opinion, the language server protocol lets the server specify if a doc string is Markdown or plaintext, and we do mark it as Markdown in SuperHTML.

Related upstream issue: helix-editor/helix#11175

My suggestion would be to open an upstream issue (I couldn't find one about this specific case).
Consider also linking this issue in the upstream issue, since SuperHTML is configured by default for HTML in Helix.

[kristoff-it]

As a temporary workaround I would be happy to accept a patch to src/cli/lsp.zig that detects if the client is Helix and does some processing to documentation strings before sending them to Helix.

[adiabatic]

The formally correct answer is that in Markdown a single newline does not constitute a break in the rendered output, meaning that in this case it's Helix that is rendering Markdown wrong.

Oh, right. I forgot.

My suggestion would be to open an upstream issue (I couldn't find one about this specific case).

Good idea — I’ll go do that, instead. Thanks for linking to a pretty-close match!

Close this one as a WONTFIX, then?

[kristoff-it]

As I mentioned earlier, I'm open to adding client detection to preprocess the description string before sending it to the LSP client, so I'll leave this issue open to track that effort, if anybody wants to take it on, and/or to track an upstream issue.