Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Support mark (highlight) extension #67

Merged
merged 3 commits into from
Sep 27, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions bin/lunamark
Original file line number Diff line number Diff line change
Expand Up @@ -281,6 +281,10 @@ environment variable `LUNAMARK_EXTENSIONS` (see ENVIRONMENT below).
: Enable strike-through support for a text enclosed within double
tildes, as in `~~deleted~~`.

`(-) mark`
: Enable highlighting support for a text enclosed within double
equals, as in `==marked==`.

`(-) subscript`
: Enable superscript support. Superscripts may be written by surrounding
the subscripted text by `~` characters, as in `2~10~`.
Expand Down Expand Up @@ -519,6 +523,7 @@ given in parentheses:
(-) fancy_lists Pandoc style fancy lists
(-) task_list GitHub-Flavored Markdown task list
(-) strikeout Strike-through with double tildes
(-) mark Highlight with double equals
(-) subscript Subscripted text between tildes
(-) superscript Superscripted text between circumflexes
(-) bracketed_spans Spans with attributes
Expand Down Expand Up @@ -590,6 +595,7 @@ local extensions = { -- defaults
fancy_lists = false,
task_list = false,
strikeout = false,
mark = false,
subscript = false,
superscript = false,
bracketed_spans = false,
Expand Down
26 changes: 23 additions & 3 deletions lunamark/reader/markdown.lua
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,7 @@ parsers.citation_chars = parsers.alphanumeric
parsers.internal_punctuation = S(":;,.?")

parsers.doubleasterisks = P("**")
parsers.doubleequals = P("==")
parsers.doubleunderscores = P("__")
parsers.doubletildes = P("~~")
parsers.fourspaces = P(" ")
Expand Down Expand Up @@ -742,6 +743,10 @@ end
-- : Enable strike-through support for a text enclosed within double
-- tildes, as in `~~deleted~~`.
--
-- `mark`
-- : Enable highlighting support for a text enclosed within double
-- equals, as in `==marked==`.
--
-- `superscript`
-- : Enable superscript support. Superscripts may be written by surrounding
-- the superscripted text by `^` characters, as in `2^10^.
Expand Down Expand Up @@ -912,11 +917,14 @@ function M.new(writer, options)
-- Basic parsers (local)
------------------------------------------------------------------------------

local specials = "*_~`&[]<!\\-@^"
if options.smart then
larsers.specialchar = S("*_~`&[]<!\\'\"-.@^")
else
larsers.specialchar = S("*_~`&[]<!\\-@^")
specials = specials .. "'.\""
end
if options.mark then
specials = specials .. "="
end
larsers.specialchar = S(specials)

larsers.normalchar = parsers.any - (larsers.specialchar
+ parsers.spacing
Expand Down Expand Up @@ -1195,6 +1203,12 @@ function M.new(writer, options)
parsers.doubletildes)
) / writer.strikeout

larsers.Mark = parsers.between(parsers.Inline, parsers.doubleequals,
parsers.doubleequals)
/ function (inlines)
return writer.span(inlines, { class="mark" })
end

larsers.Span = ( parsers.between(parsers.Inline, parsers.lbracket,
parsers.rbracket) ) * ( parsers.attributes )
/ writer.span
Expand Down Expand Up @@ -1784,6 +1798,7 @@ function M.new(writer, options)
+ V("Emph")
+ V("Span")
+ V("Strikeout")
+ V("Mark")
+ V("Subscript")
+ V("Superscript")
+ V("InlineNote")
Expand All @@ -1809,6 +1824,7 @@ function M.new(writer, options)
Emph = larsers.Emph,
Span = larsers.Span,
Strikeout = larsers.Strikeout,
Mark = larsers.Mark,
Subscript = larsers.Subscript,
Superscript = larsers.Superscript,
InlineNote = larsers.InlineNote,
Expand Down Expand Up @@ -1863,6 +1879,10 @@ function M.new(writer, options)
syntax.Strikeout = parsers.fail
end

if not options.mark then
syntax.Mark = parsers.fail
end

if not options.raw_attribute then
syntax.RawInLine = parsers.fail
end
Expand Down
10 changes: 10 additions & 0 deletions lunamark/writer/html5.lua
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,8 @@ function M.new(options)
options = options or {}
local Html5 = html.new(options)

local htmlSpan = Html5.span -- inherited, for overriding

Html5.container = "section"

Html5.template = [[
Expand All @@ -36,6 +38,14 @@ $body
return {"<del>", s, "</del>"}
end

function Html5.span(s, attr)
-- HTML5 has semantic <mark>
if attr.class == "mark" then
return {"<mark>", s, "</mark>"}
end
return htmlSpan(s, attr)
end

return Html5
end

Expand Down
5 changes: 5 additions & 0 deletions tests/lunamark/ext_mark.test
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
lunamark -Xmark
<<<
Some ==highlighted text==.
>>>
<p>Some <span class="mark">highlighted text</span>.</p>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regardless, done in 96c05c8

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.