The check was introduced with d28de22, when fixing #172 and #173.
Then I removed it with bcd6dd8 when fixing #180
And then it was reintroduced with 232d06c when fixing regression.
It seems that the check can be removed again. All these cases now have
tests (including the one from 69f51af, which seems to have landed to v1
only, copying it here) and they all pass.
Clean up footnotes part of an AST: don't force HTML-specific pieces
there, just keep a clean list of footnotes. Since some renderers might
want to process footnotes differently, let them know about footnotes by
having a flag on that list.
Separate Smartypants somewhat from the HTML renderer. Move its flags
from HtmlFlags to Extensions (probably should be moved to its own set of
flags, but not now). With that done, do a separate walk of the tree and
either run Smartypants processor if it's enabled, or simply escape text
nodes.
This commit does some changes to the test suite. The changes are only to
the newlines. Turns out the former implementation of footnotes produced
slightly different spacing when rendering the footnotes list. The new
implementation produces the list that is compatible with the rest of the
package.
Autolink detection used to be triggered by a colon and preceding
protocol name used to be rewound. Now instead of doing that, trigger
autolink processing on [hmfHMF] and see if it looks like a link.
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.
This is both nasty and neat at the same time. All the code could handle
nested footnotes just fine, the only place that was not working was the
final loop that printed the list. The loop was in a range form, which
couldn't account for another footnote being inserted while processing
existing ones. Changing the loop to the iterative form solves that.
Closes#193.
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.
This changes HTML renderer not to always add a newline character after
<img> tags. This is desirable because <img> tags can be inlined, and
sometimes you want to avoid whitespace on left and right sides. Previous
behavior of always adding a newline would unavoidably create whitespace
after <img> tag.
Update all tests to match new behavior. There are few changes, and
they're completely isolated to inline image tests.
Fixes#169.
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.
The flag `HTML_SMARTYPANTS_ANGLED_QUOTES` combined with `HTML_USE_SMARTYPANTS` configures rendering of double quotes as angled left and right quotes (« »).
The SmartyPants documentation mentions a special syntax for these, `<<>>`, a syntax neither pretty nor user friendly.
Typical use cases would be either or, or combined, but never in the same document. As an example would be a person from Norway; he has a blog in both English and Norwegian (his native tounge); he would then configure Blackfriday to use angled quotes for the Norwegian section, but keep them as reqular double quotes for the English.
If the flag `HTML_SMARTYPANTS_ANGLED_QUOTES` is not provided, everything works as before this commit.
