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 problem was in a loop that skipped the optional closing hashes in a
heading like this:
### This is an H3 ###
Now it checks to see if a hash is escaped and if it is, treats it as a
rightmost character of the heading text, like this:
### This is an H3 #\## ==> ### This is an H3 ##
Fixes issue #146.
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.
The original upskirt library by Natacha Porté has been renamed to
libsoldout, while the fork of it that was located at tanoku/upskirt has
been renamed to Sundown and moved to vmg/sundown. Since Blackfriday has
been started as a translation of tanoku/upskirt, rename its mention in
README to Sundown.
It's pretty standard to have a license file, and some projects require
them before your code can be used in their code. Move the license to
its own file.
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.
Apply gofmt on html.go.
Apply goimports-compatible formatting on block.go (space between standard and third party imports).
Move Travis build status image in a more pleasing, common location.
Remove "Markdown pretty-printer output engine" from TODO steps; this is already done in markdownfmt.
Remove unneeded trailing whitespace in README.
Fix a minor issue in expected anchor after recent PR. The tests were written before the improvement that squashes non-alphanumeric characters into a single dash, and does not include dashes at the beginning and end. This updates the test case to match that behavior so that tests pass and Travis is green.
This is specifically driven by the Hugo usecase where multiple documents
are often rendered into the same ultimate HTML page.
When a header ID is written to the output HTML format (either through
`HTML_TOC`, `EXTENSION_HEADER_IDS`, or `EXTENSION_AUTO_HEADER_IDS`), it
is possible that multiple documents will hvae identical header IDs. To
permit validation to pass, it is useful to have a per-document prefix or
suffix (in our case, an MD5 of the content filename, and we will be
using it as a suffix).
That is, two documents (`A` and `B`) that have the same header ID (`#
Reason {#reason}`), will end up having an actual header ID of the form
`#reason-DOCID` (e.g., `#reason-A`, `#reason-B`) with these HTML
parameters.
This is built on top of #126 (more intelligent collision detection for
`EXTENSION_AUTO_HEADER_IDS`).
> This is a rework of an earlier version of this code.
The automatic header ID generation code submitted in #125 has a subtle
bug where it will use the same ID for multiple headers with identical
text. In the case below, all the headers are rendered a `<h1
id="header">Header</h1>`.
```markdown
# Header
# Header
# Header
# Header
```
This change is a simple but robust approach that uses an incrementing
counter and pre-checking to prevent header collision. (The above would
be rendered as `header`, `header-1`, `header-2`, and `header-3`.) In
more complex cases, it will append a new counter suffix (`-1`), like so:
```markdown
# Header
# Header 1
# Header
# Header
```
This will generate `header`, `header-1`, `header-1-1`, and `header-1-2`.
This code has two additional changes over the prior version:
1. Rather than reimplementing @shurcooL’s anchor sanitization code, I
have imported it as from
`github.com/shurcooL/go/github_flavored_markdown/sanitized_anchor_name`.
2. The markdown block parser is now only interested in *generating* a
sanitized anchor name, not with ensuring its uniqueness. That code
has been moved to the HTML renderer. This means that if the HTML
renderer is modified to identify all unique headers prior to
rendering, the hackish nature of the collision detection can be
eliminated.