rendering of html comments do not work anymore

[u-fischer]

\documentclass{article}
\usepackage{markdown}
\markdownSetup{
  renderers = {
    inlineHtmlComment = {show this #1!},    
  },
}
\begin{document}
\begin{markdown}
A useful use of inline HTML comments are side notes.
<!-- Side notes are displayed in the horizontal margins next to the relevant
passages, which makes them *easier for the reader to find* than notes. -->
\end{markdown}
\end{document}

With texlive 2023 I get the expected output:

With texlive 2024 and newer the comment is not shown:

[Witiko]

This seems to be a consequence of our CommonMark compliance starting with version 3.0.0 of the Markdown package. In CommonMark, any HTML tag, comment, or processing instruction that starts a line interrupts a paragraph and produces an HTML block. In the Markdown package, this produces the inputBlockHtmlElement renderer surrounded by interblockSeparator renderers. (The name inputBlockHtmlElement is somewhat confusing, since the HTML block may contain an HTML fragment, not just a (single) element.)

For the inlineHtmlComment renderer to be produced by the Markdown package, the HTML comment needs to be understood as raw (inline) HTML by CommonMark, which you can achieve by having some text on the line before the HTML comment:

A useful use of inline HTML comments are side notes. <!-- Side notes are
displayed in the horizontal margins next to the relevant passages, which
makes them *easier for the reader to find* than notes. -->

As discussed in #597 (comment), we might add a new parsing regime for HTML that would produce more useful renderers instead of the catch-all renderer inputBlockHtmlElement. However, a CommonMark-compliant parser will always interpret an HTML comment on a line of its own as paragraph-interrupting and there's not much we can do about that without breaking compliance.

[Witiko]

However, a CommonMark-compliant parser will always interpret an HTML comment on a line of its own as paragraph-interrupting and there's not much we can do about that without breaking compliance.

Come to think of it, we could add an new option blankBeforeHtmlBlock that would break CommonMark compliance by requiring a blank line before any HTML block in the middle of a paragraph. This would cause us to produce the inlineHtmlComment renderer more frequently, similar to before version 3.0.0 of the Markdown package. However, HTML comments with no preceding text would still be understood as HTML blocks, so this is just a partial solution to the problem.