| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deprecated naming support is removed:
* Removed special treatment for modules in `markdown.extensions`
* Removed support for `mdx_` prefixes.
Support for Entry Point names added:
Support for "short names" are now implemented with entry points.
Therefore all the users who call extension names as `toc` will not
get errors as the builtin extensions all have entry points defined
which match the old "short names" for modules in
`markdown.extensions`. The benefit is that any extension can offer
the same support without requiring the user to manually copy a file
to that location on the file system (way to many extension authors
have included such instructions in their installation documentation).
The one odd thing about this is that we have been issuing a
DeprecationWarning for short names and now they are fully supported
again. But I think it's the right thing to do.
Support for using dot notation is not removed. After all, it was never
deprecated. And we shouldn't "force" entry points. There are plenty of
reasons why users may not want that and not all of them can be
resolved by using class instances instead.
All of the following ways to load an extension are valid:
# Class instance
from markdown.extensions.toc import TocExtension
markdown.markdown(src, extensions=[TocExtension()]
# Entry point name
markdown.markdown(src, extensions=['toc'])
# Dot notation with class
markdown.markdown(src, extensions=['markdown.extensions.toc:TocExtension'])
# Dot notation without class
markdown.markdown(src, extensions=['markdown.extensions.toc'])
|
| | |
|
| |
|
|
|
|
| |
* Install deps.
* Ensure test fails if deps are missing.
* Update dictionary for recent docs changes.
|
| |
|
|
|
| |
Ancestry exclusion for inline patterns.
Adds the ability for an inline pattern to define a list of ancestor tag names that should be avoided. If a pattern would create a descendant of one of the listed tag names, the pattern will not match. Fixes #596.
|
| | |
|
| | |
|
| | |
|
|
|
Not sure this is the best way to go, but it works. I'm not crazy about
running the spellcheck against the built docs, but aspell has a builtin
option to easily ignore everything in `<code>` tags which greatly simplfies
things.
I looked at Doug Hellmans' sphinxcontrib-spelling package which does
something similar for Sphinx. However, as Sphinx uses rST and the rST
parser outputs a parse tree, Doug is essentially taking that parse tree
and running the spellcheck on the appropriate parts (skipping code, etc.).
He did a nice [writeup][5] of his development process if you are interested.
As Python-Markdown's parse tree is represented as HTML (through ElementTree)
I would have to use HTML anyway. And [PyEnchant][2] doesn't currently have
good support for HTML. So I used [aspell][3], with inspiration from the
[git-spell-check][4] hook.
[1]: http://sphinxcontrib-spelling.readthedocs.org/en/latest/index.html
[2]: https://pythonhosted.org/pyenchant/
[3]: http://aspell.net/
[4]: https://github.com/mprpic/git-spell-check
[5]: http://doughellmann.com/2011/05/26/creating-a-spelling-checker-for-restructuredtext-documents.html
|
