feat: Support mark (highlight) extension

[Omikhleia]

The extension is disabled by default.
When enabled, ==marked== is expanded to a span with class "mark", for parity with upcoming Pandoc, and also Djot's {=marked=}.

Closes #65

[Witiko]

Thanks for the implementation, seems straightforward. Will be porting this to witiko/markdown in Witiko#303, so I am leaving this open in case I discover some edge cases that would best be fixed.

for parity with [...] Djot's {=marked=}.

Only ==marked== is supported, though? Do you have any ambition to implement Djot's syntax as well, or are you just name-dropping Djot? 😃

[Omikhleia]

Only ==marked== is supported, though? Do you have any ambition to implement Djot's syntax as well, or are you just name-dropping Djot?

Sorry if it sounded name-dropping, it wasn't my intention 🐱
My Markdown for SILE collection of packages now supports both Markdown (based on the lunamark reader) and Djot (based on the djot.lua reader).
Since the SILE rendering part uses several common functions as an attempt to reuse as much code as possible (after all, they have a whole lot in common), that's just how I actually got aware of the == support recently added to Pandoc... I hadn't noticed it before. I refactored my code to add support simultaneously for both markup languages in my implementation (Omikhleia/markdown.sile#70)... and then proceeded to propose a "backport" as a PR here for the lunamark side of things. That's all ;-)

[Witiko]

In HTML5, there is a <mark> element. The HTML5 writer should likely produce <mark> rather than <span class="mark">. No need to test that, but we should likely add a new function mark() to writers rather than reuse the span() function even if the output will still be <span class="mark"> in the HTML writer.

[Omikhleia]

Last time I checked, Pandoc just expands a span here, so I went for the simplest choice.
Of course we can possibly support outputting a <mark> in the HTML5 writer - either as suggested with a mark() function in writers, or possibly in the HTML5 writer itself, interpretating that span (avoiding yet another writer method for so small a thing).

[Witiko]

My distro didn't have a recent enough Pandoc for me to check, but Pandoc tests suggest that Pandoc also produces the <mark> element. Regardless, it seems clear to me that we should produce semantic HTML5 markup like <mark> whenever possible.

[Omikhleia]

It's not part of the Pandoc AST https://hackage.haskell.org/package/pandoc-types-1.23/docs/Text-Pandoc-Definition.html#t:Inline

And indeed ==mark== processed with -f markdown+mark -t json gives

{"pandoc-api-version":[1,23,1],"meta":{},"blocks":[{"t":"Para","c":[{"t":"Span","c":[["",["mark"],[]],[{"t":"Str","c":"mark"}]]}]}]}

If I correctly read the code, the Pandoc Markdown reader indeed uses a span here:
https://github.com/jgm/pandoc/blob/edbea270f5ed0cae23cfe977b9621045256e7dfc/src/Text/Pandoc/Readers/Markdown.hs#L1726

Wondering where it does the mapping then! But it might thus likely be somewhere in Writers?

[Omikhleia]

Regardless, done in 96c05c8

[Witiko]

Wondering where it does the mapping then! But it might thus likely be somewhere in Writers?

Seems that way. I was able to pinpoint a number of writers, which produce special output for spans with the mark class name:

• https://github.com/jgm/pandoc/blob/2c6f22d2b4edd9fb8b8576995d7aece99feef207/src/Text/Pandoc/Writers/LaTeX.hs#L765
• https://github.com/jgm/pandoc/blob/2c6f22d2b4edd9fb8b8576995d7aece99feef207/src/Text/Pandoc/Writers/Docx.hs#L1193
• https://github.com/jgm/pandoc/blob/2c6f22d2b4edd9fb8b8576995d7aece99feef207/src/Text/Pandoc/Writers/OpenDocument.hs#L611
• https://github.com/jgm/pandoc/blob/2c6f22d2b4edd9fb8b8576995d7aece99feef207/src/Text/Pandoc/Writers/RST.hs#L755
• https://github.com/jgm/pandoc/blob/2c6f22d2b4edd9fb8b8576995d7aece99feef207/src/Text/Pandoc/Writers/Markdown/Inline.hs#L351

I wasn't able to pinpoint where the HTML writer does it.