| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
homepage).
|
|
|
|
| |
the headerid extension.
|
| |
|
|
|
|
| |
first line of a code block for codehilite to recognize it.
|
|
|
|
|
|
|
|
|
|
| |
This is an extension which alters the behavior of lists to be less surprising.
If turned out to be rather simple to code. I'm surprised no one had written it
yet.
I should note that this extension does not generate separate lists if different
unordered list markers are used (`*` verses `-` verses `+`) The way the parser
works that would be a little more tricky.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
type.
|
| |
|
|
|
|
| |
work with it.
|
|
|
|
| |
capitalized. Thanks 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.
|
|
|
|
| |
extension source
|
|
|
|
| |
used by github
|
|
|
|
| |
code to provide a few other minor improvements s that output more closely matches php's output. Thus the changes in the tests.
|
|
|
|
| |
someday we will better support any input (patches welcome), but we should never crash on poorly formatted input text. With this fix, we catch the exception and skip over it. The TOC up to the point (and perhaps after) still gets rendered. The incomplete TOC should be the clue to the document author that s/he has a formatting error in the document.
|
|
|
|
| |
from the command line style syntax for passing in bool type extension configs. In order words, we now except strings in addition to booleans and integers.
|
|
|
|
| |
if a marker was not found in the document.
|
|
|
|
| |
of python. Note: one test (meta) is still failing on Python 3 due to unicode strings.
|
|
|
|
| |
function. The url is being encoded (with errors ignored) as an easy means of removing non-ascii chars, but we have to re-encode it *before* running the regex on it, not after.
|
| |
|
| |
|
| |
|
|
|
|
| |
code blocks/spans. A better fix for #4: Only the *text* from the header is caried over to the toc (without *any* inline formatting). Also refactored the extension to better work in tandem with the refactored headerid extension and the new attr_list extension.
|
|
|
|
| |
Force input and output of tidy to use UTF-8 and encode before and decode after passing in the text.
|
|
|
|
| |
autogenerates ids. If you want to define your own, use the attr_list extension. Also expanded HeaderId extension to use the same algorithm as the TOC extension (which is better) for slugifying the header text. Added config settings to override the default word separator and the slugify callable. Closes #16 as the reported bug is for a removed feature.
|
|
|
|
| |
Thanks to skurfer for report and inital patch.
|
|
|
|
| |
and allowing us to use it.
|
|
|
|
| |
closes #24
|
|
|
|
| |
See issue #7. Also likely to become a replacement for the headerid extension (with a little more work - need a forceid option) which means it will also address issue #16. The extension works with some limited testing. Still needs tests and documentation. Currently breaks toc extension - which should run after attr_list, not before.
|
|
|
|
| |
for pointing out the typo.
|
|
|
|
| |
now include smart handling of double underscores (not just single underscores). The new behavior may be called seperately as the 'smart_strong' extension or as part of the 'extra' extension.
|
| |
|
| |
|
| |
|
|
|
|
| |
configs. No more self.config['name'][0] weirdness anymore.
|
|
|
|
| |
a 'default' keyword and added Extension.getConfigs which returns a list of tuples of all settings without the descriptions.
|
|
|
|
| |
happen every time a block is highlighted. Not sure why I didn't do it this way to begin with.
|
|
|
|
| |
simpler markup which should allow for the use of JavaScript Highlighting libraries. In other words, no pygments like <div> and no <ol> for line numbering. Just a <pre><code> block with classes assinged to them. If people want fancier stuff, they can use JavaScript or create their own extension.
|
|
|
|
| |
"Weve got a problem header". We log a warning - not raise an exception.
|
|
|
|
| |
sys.exit()) and raise appropriate exceptions instead. backwards incompatible insofar as custom extensions may need tweaks if they're using old markdown logging (but they shouldn't, it was gross)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implicit syntax (existing):
tag: Python
Markdown
Explicit syntax (new):
tag: Python
tag: Markdown
These two examples are now equivalent. Previously, the latter would produce
`{u'tag': [u'Markdown']}` rather than `{u'tag': [u'Python', u'Markdown']}`.
|
|
|
|
| |
example, hyphens to be used rather than underscores.
|
| |
|
|\ |
|
| |
| |
| |
| | |
extensions. All behavior is now within the class.
|
|/ |
|
|
|
|
| |
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.
|