slachiewicz opened a new pull request, #1076:
URL: https://github.com/apache/maven-doxia/pull/1076

   Part of #876 (DOXIA-762), which asks for the Markdown side of code 
highlighting to be written down somewhere. The module page currently says 
nothing about code blocks at all.
   
   Two things here.
   
   **The module page gains a "Code blocks" section.** Verified against the 
current parser rather than inferred:
   
   | Markdown | inline event class | rendered |
   | --- | --- | --- |
   | ` ```java ` | `language-java` | `<pre><code class="language-java">` |
   | ` ``` ` with no info string | `nohighlight nocode` | `<pre><code 
class="nohighlight nocode">` |
   | indented block | `nohighlight nocode` | `<pre><code class="nohighlight 
nocode">` |
   
   The first row is asserted by `fencedCodeBlockSinkEvent` in the module's own 
tests. I confirmed the indented case by dumping the events for `code.md`, since 
only the fenced case was covered. The two odd class names come from 
`FENCED_CODE_NO_LANGUAGE_CLASS` and are the opt-out markers for highlight.js 
and code-prettify, which is worth stating since they look arbitrary otherwise.
   
   **The `MarkdownHtmlParser` javadoc is corrected.** It currently says:
   
   > PRE elements need to be "source" because the Xhtml5Sink will surround the 
corresponding verbatim() Sink event with a DIV element with class="source", 
which is how most Maven Skin (incl. Fluido) recognize a block of code
   
   That is no longer what happens, and the module's own test comment says as 
much: *"instead of using a decoration tag on the verbatim event an additional 
inline event is used"*. The `verbatim` event carries no attributes; the nested 
`inline` event carries the semantics and the language. Leaving the old 
description in place is worse than having none, since it points at a mechanism 
that is not there.
   
   The replacement also records why Markdown differs from APT and XDoc, where 
`+--` and `<source>` put the `source` decoration on the `verbatim` event: 
Markdown has a language to convey as well, and the inline event already carries 
it, so the decoration would add nothing.
   
   This does not close #876 on its own. The APT half is 
apache/maven-doxia-site#70, and whether the four parsers should converge on one 
representation is a separate question I have deliberately not touched here.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to