| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| | |
The previous requirements are incorrect, the method needs to accept two
parameters.
|
|/
|
|
|
|
|
|
| |
By default, this only supports YAML deliminators (`---`) and adds no
additional behavior. In other words, parsing is unchanged. However, with
the `yaml` option set, PyYAML will parse the metadata.
Thanks to @kernc for suggesting the idea and doing the work on this.
|
| |
|
|
|
| |
Fixes #359. Thanks for the report @gremmie.
|
|
|
|
| |
Also removed an inacurate statement in the 2.5 release notes.
|
| |
|
|
|
|
|
| |
Both `safe_mode` and `html_replacement_test` keywords are
pending deprecation, as are positional args. Closes #337.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The builtin extensions will no longer get special treatment and have
the path ("markdown.extensions.") appended . The same applies for
"mdx_" extensions. All names extension must provide the full path.
Fixes #336.
Also deprecating support for passing in extension config settings
as part of the string name. The extension_configs keyword should
be used instead. Fixes #335.
Also raising PendingDeprecationWarnings for positional args or the
"config" keyword on the Extension Class. Pass each setting as a
seperate keyword instead.
Docs and tests are updated. Still need to update extension API docs.
|
|
|
|
|
| |
This is in anticipation of #335. The reference and extension api docs still
need to be updated, but that will happen with change in the code.
|
|
|
|
|
|
| |
Except were "short names" are explained in the docs, all references
to the buitlin extensions now use `markdown.extensions.*` in
anticipation of #336.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you were to import the class like this:
from path.to.module import SomeExtensionClass
Then the named extension would be the string:
"path.to.module:SomeExtensionClass"
This should simplify loading extensions from the command line or
template filters -- expecially when multiple extensions are defined
in a single python module.
The docs still need updating. I'm waiting to update the docs after
implementing #335 and #336 as that will require a major refactor of
that section of the docs anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now use importlib which means we no longer support Python 2.6.
Also, this refactor properly imports third party extensions which reside
at the root of PYTHONPATH. Previously, either `markdown.extensions.` or
`mdx_` would be appended to any extension name that did not contain a
dot, which required third party extensions to either be in submodules or
use the old `mdx_` naming convention.
This commit is also in preperation for #336. It will now be much easier to
deprecate (and later remove) support for the old ways of handling extension
names.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The `--extension_configs` option must point to a YAML or JSON file.
The contents of the file must parse to a Python Dict which will be
passed to the `extension_configs` keyword of the `markdown.Markdown`
class.
Also added tests for all of the CLI option parsing options and updated
documentation.
|
| |
|
| |
|
|
|
|
| |
Related to #325
|
| |
|
|
|
|
| |
allows to overwrite all substitution strings. Fixed line length in docs.
|
|
|
|
| |
to replace quotes. This makes it possible to use the correct quotes in languages other than English.
|
|
|
| |
Relates to #325.
|
|
|
| |
Noted that using keywords it the prefered method of passing config options to extensions. Also updated the example sto demonstrate the new prefered way as discussed in #325.
|
|
|
|
| |
See <http://en.wikipedia.org/wiki/Guillemet>.
|
|
|
|
| |
This is related to waylan/Python-Markdown#305.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Simplified, unified style, added some undocumented options.
NOTE: Footnotes/UNIQUE_IDS stays mostly undocumented
|
| |
|
|
|
| |
chaining calls, not changing calls
|
|
|
| |
Fixed "you're"/"your" mixup. Sorry.
|
| |
|
|
|
| |
Must remember to spellcheck everything I type.
|
|
|
| |
This addresses a misunderstanding reported in issue #273. The behavior has not changed. The docs just better reflect the actual behavior better. Apparently using the word "definition" both for footnotes and definition lists was an unfortunate coincidence that created confusion. We now use the term "footnote content".
|
|\
| |
| | |
miscellaneous issue52 improvements
|
| | |
|
|/ |
|
|
|
| |
Fixed #261. Thanks for the report @mpvharmelen.
|