Closed ayazhafiz closed 3 years ago
Thanks!
Yeah, I think trimming any trailing whitespace is probably a reasonable call for all Twoslash code samples. For the TS/JS languages we're focused on, I can't think of a good reason to have trailing whitespace on a code sample.
First of all, thank you for your work on this software. It's one of more exciting things I've seen in the developer space since the LSP; I wish you success in your vision.
It seems that markdown-it preserves the trailing newline in a code block when parsing it and passing it to a custom highlighter. For example,
is parsed as
// a\n
. On the shiki-twoslash side, the trailing newline is treated as its own line, producing the htmlThe issue here is that the trailing newline has been "pushed up" as its own block-layed-out line in the pre, making the rendered code appear as if it has an explicit trailing newline even when the intention is not to do so.
What do you think of this? I think the most reasonable solution is just to chop of the trailing newline in the code parsed by markdown-it (verified this removed the trailing line with a non-breaking space); since markdown-it conforms to commonmark, we can expect that code blocks are parsed with a trailing newline before closing with
</code></pre>
(spec). Maybe guarding behind an option is good too, but imo this is a bit of technical detail for that to be useful.I am happy to send a patch if this issue is reasonable and there is a good idea for a solution.