| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
A `from __future__ import ...` statement must go after any docstrings;
since putting them before the docstring means the docstring loses its
magic and just becomes a string literal. That then causes a syntax
error if there are further future statements after the false docstring.
This fixes issue #203, using the patch provided by @Arfrever.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The most notable changes are the use of unicode_literals
and absolute_imports. Actually, absolute_imports was the
biggest deal as it gives us relative imports. For the first
time extensions import markdown relative to themselves.
This allows other packages to embed the markdown lib in a
subdir of their project and still be able to use our
extensions.
|
| |
|
|
|
| |
Previously they contained colons - and they still do for HTML4 and XHTML.
Fixes #180.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As HTML5 has depreciated use of `rev=anything` and `rel=footnotes`, they are no
longer inlcuded in the output when the output_format is set to HTML5. Note that
if someone successful registers a spec for `rel=footnotes` in the future (as
a microformat), then that could be considered valid. But until that happens,
it is invlaid to use in HTML5. Therefore, we remove it from the output (when
outputing HTML% only).
As an alternative, two new classes are set (in all output_formats). On the link
to the footnote (where `rel=footnotes` was used), we set `class=footnote-ref`
and on the backlink (where `rev=footnote` was used), we set
`class=footnote-backref`.
Also updated the tests to reflect to the new classes in the output.
|
| |
|
|
|
|
|
|
| |
The footnotes treeprocessor must be the first one run so that all others,
including codehilite's, can run on the contents of the footnote div which is
created and inserted by the footnotes treeprocessor.
Thanks to startling for the report.
|
| |
|
|
|
| |
I accidentally changed the wrong line (L294 instead of L293) to
"self.footnotes.getConfig("BACKLINK_TEXT")" before. This fixes that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BACKLINK_TEXT specifies the text that's used in the link at the end of
the footnote to link back up to the reader's place. It still defaults to
"↩".
Okay, so at first I had an uncessarily complicated commit for this and
submitted a pull request. Waylan showed me a better way to do it, here:
https://github.com/startling/Python-Markdown/commit/ee7d1a26c76f970c12226ca48ba52dc1d32f2488#markdown/extensions/footnotes.py-P19
So I made another commit and added it to the pull request. But then I
accidentally added yet another commit to the pull request, accidentally.
Since then, I've realized it would be best to start with a new branch
and closed that first pull request.
Hopefully this will be the last try.
|
| |
|
|
| |
code to provide a few other minor improvements s that output more closely matches php's output. Thus the changes in the tests.
|
| |
|
|
| |
coresponding definition no longer raise an error. They now pass through as plain text - which is the same behavior as PHP Markdown Extra. Thanks for the report Benjamin Bach.
|
| |
|
|
| |
markdown document results in the placeholder actually being replaced. Also added a test for this. Note that if the placeholder paragraph has other text, that text is lost. Not sure if this is a bug or bad markdown syntax.
|
| |
|
|
| |
should have been removed excatly 2 years and 3 days ago (commit bd185087dc899b6157f8) when elementtree support was added. And to think it has been generating an error the whole time and was only just reported now. It appears this was never tested as it still does not work after removing the old line. At least we do not get an error. The footnote placeholder is just an empty paragraph. Thanks for the report Evan Carmi.
|
| | |
|
| |
|
|
| |
if they desire.
|
| |
|
|
|
| |
contain footnotes with the same name, they will no longer collide when
'UNIQUE_IDS' is set to True. Thanks to Paul Stansifer for report and patch.
|
| | |
|
|
|
package instead of two.
|
