These will be helpful for catching regressions or changes in behavior
to edge cases such as empty input, or specifically crafted inputs that
may cause panics, etc.
Move test for issue #172 there since it's a document-level test, not an
inline one.
Add test for issue #173.
Make some things more consistent.
Don't use a named receiver in methods that don't use it. This makes the
code more readable since one can more quickly tell the inputs to the
method.
This is purely a style change with no behavior difference.
In Go (unlike most other languages), case statements in a switch
don't need an explicit break statement, it happens by default. Adding
it explicitly is possible, but has no effect.
In this case, having the break statement hurts readability because
it's hard to tell if it's a mistake, and the break was intended to
break out of the outer for loop, rather than do nothing for the switch
statement. So, remove it, to make it more clear that there is no
bug here.
Also make tip a fast-finish allowed failure. That way, if CI fails on
tip due to a temporary issue with tip, it will not break build status.
However, it's still possible to see tip build status by looking at CI
details page.
Do not run go vet with Go 1.4 or older since it's not included in the
standard library, and it's no longer available in external standard
library.
Add godoc badge to README.md.
Instead of swallowing an empty line and then reintroducing it back again
in certain cases, collect the list item body in an unaltered form and
let the recursive parsing call sort things out.
Fixes issue #228.
This is a better style for a set, since each value can only be present
or absent.
With bool as value type, each value may be absent, or true or false. It
also uses slightly more memory.
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.
Dmitri Shuralyov
Vytautas Šaltenis
Cameron Moore
Tom Kwok
Shawn Smith
shawnps
Nat Welch
Alex Yatskov