Link parser interpreted the sequence "![^foo]" as an image, but if
footnote extension is enabled, it's quite clear that it should be
interpreted as a footnote following something with an exclamation point
at the end.
Closes#194.
When parsing a deferred footnote, we already know it's a footnote from
the '[^' part, so we can use that to hit a proper switch branch
(default) a bit later on.
Closes#164.
Start searching for emphasis character at 0th index instead of 1st.
Fixes a corner case with doubly emphasised code span followed by
another code span on the same line.
Changes interpretation of improperly nested emphasis, hence the change
in TestEmphasisMix().
Closes#156.
The second footnote was treated as if the pair of them were a reference
style link, without checking if the second bit is another footnote.
Fixes issue 158.
If a user provides a ReferenceOverride function, then reference ids
will be passed to the given ReferenceOverride function first, before
consulting the generated reference table.
The goal here is to enable programmable support for
"WikiWords"-style identifiers or other application-specific
user-generated keywords.
Example, writing documentation:
The [Frobnosticator][] is a very important class in our codebase.
While it is used to frobnosticate widgets in general, it can also
be passed to the [WeeDoodler][] to interesting effect.
This might be solveable with the HTML Renderer relative prefix, but
I didn't see a good way of making a short link to 'Frobnosticator'
relatively without having to write it twice. Maybe
'<Frobnosticator>' should work? Should Autolinks work for relative
links?
In addition, I wanted a little more richness. I plan to support
Godoc links by prefixing references with a '!', like so:
Check out the [Frobnosticator][] helper function
[!util.Frobnosticate()][]
The first link links to the Frobnosticator architectural overview
documentation, whereas the second links to Godoc.
Better advice on how to implement this sort of think with
Blackfriday is highly desired.
When checking if it's a newline preceeded by two spaces, look at the input data rather than the output, since the output depends on the renderer implementation.
Use an HTML5 compliant parser that interprets HTML as a browser would to parse
the Markdown result and then sanitize based on the result.
Escape unrecognized and disallowed HTML in the result.
Currently works with a hard coded whitelist of safe HTML tags and attributes.
When the source Markdown contains an anchor tag with URL as link text
(i.e. <a href=...>http://foo.bar</a>), autolink converts that link text
into another anchor tag, which is nonsense. Detect this situation with
regexp and early exit autolink processing.
