| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
`'path.to.module(option=value'` => `path.to.module.Class(option='value')`
This is in anticipation of #335
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The last few extensions were updated to accept dicts/**kwargs as configs and more
tests were updated. Also updated extra to actually accept configs.
Note that extra requires an extra level of dicts. First you need
to indicate tha the settings are for extra, then, which extension
extra wraps. I'm not crazy abount this, bit not sur ehow else to do it
without making all the configs a global attribute on the Markdown class
to that any extention can access any other extensions config settings.
I don't think we wnat to do that.
Also updated extra to use dot notation for the sub-extensions.
|
| |
|
|
|
|
|
|
|
|
| |
All named extensions now use python dot notation in the tests - including
all builtin extensions (eg: 'extra' => 'markdown.extensions.extra'). This
is in anticipation of #336.
Note there are a few tests (in the error tests) that will still need
updating, but not till we make the change as they will test for the
new error message.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
markdown/inlinepatterns.py is now at 99% coverage.
I have no idea why the two remaining lines are not not covered.
I it not clear to me under what circumstances this two if statements
would ever evaluate to True. I'm inclined to just remove them, but perhaps
there is an edge case I'm missing. I'll take another look later.
|
| |
|
|
|
| |
A couple scenarios with "None" were previously not accounted for.
Also updated tests which guives us 100% for markdown/util.py
|
| |
|
|
| |
This should give us 100% coverage of postprocessors.py.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
'https://pythonhosted.org/Markdown/'. The former redirects to the latter anyway. Might as well point to the actual destination.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Dicts don't preserve order but still will be equal while lists of tuples always preserve order.
When we use a dict to create a list of tuples, the results are unpredictable - especially for
a equality test. so we need to compare dicts, not lists. Related to #325
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #325. All extensions can now accept a dict of configs or
**kwargs, not just a list of tuples. Third party extensions may want
to follow suite. Extensions may only accept keyword arguments
in the future. These changes still need to be documented.
A couple things of note:
The CodeHilite extension previously issued a DeprecationWarning
if the old config key `force_linenos` was used. With thins change,
a KeyError will now be raised.
The `markdown.util.parseBoolValue` function gained a new argument:
`preserve_none` (defaults to False), which when set to True, will
pass None through unaltered (will not convert it to False).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As pointed out in #325, setting up Extension configs is kind of a
mess. Some places pass a list of tuples on initialization, others
a dict. And sometimes they're passed as an arg, othertimes a kwarg.
Addiitonaly, the docs are just as inconsistant.
This refactor addresses all those sinerios with tests included.
The existing extensions still need refactored. But the fact that
their tests still pass means we havn't broken third party extensions
either.
This refactor also introduces a new API, which is the prefered
method going forward. All docs should be updated to match.
Whereas previously one might do:
```python
MyExtension(configs={'key': 'foo', 'otherkey': 'bar'})
```
This can now be done:
```python
MyExtension(key='foo', otherkey='bar')
```
Of course, the old way still works for backward compatability.
But that means the `configs` keyword has special status and cannot
be used for another purpose.
|
| | |
|
| | |
|
| |
|
|
| |
See <http://en.wikipedia.org/wiki/Guillemet>.
|
| |
|
|
| |
generates opening double quote.
|
| |\
| |
| | |
Make smarty extension work together with attr_list
|
| | |
| |
| |
| | |
To make it easier to notice (and fix) the failure.
|
| |/ |
|
| |
|
| |
I can't make out what this PHP test is trying to accomplish. From my point of view, our output is fine. So we skip this test.
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |\
| | |
| | | |
tables and attr_list compatibility
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes #257 and slightly alters comment parsing behavior.
Unlike self-closing tags, a comment can contain angle brackets between the
opening and closing tags. The greaterthan angle bracket at the end of the
first block should not be mistaken for closing the comment. Need to actually
check for a comment closing tag (`-->`). If one if not found, then the comment
keeps going (to the end of the document if nessecary) just like in HTML.
That last bit is a slight change from previous behavior, but should be
unsurprising as that's how broswers parse html comments. And as far as
I can tell, more implementations follow this behavior than any other. The
ones that don't seem to be all over the place.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current implementation was wrong as it also percent encoded query strings
(which should be plus encoded) and calling urllib.quote on the path (and
urllib.quote_plus on the query string) assumes the url is not already encoded.
What if the document author pasted a url that was already encoded? She probably
did not intend for `%20` to become `%2520`. Or did she? It is now clear to me
why many implementation do nothing to urls. Just pass them though as-is. To bad
if they are not valid HTML. HTML authors have to encodee their own urls, so I
guess markdown authors have to as well.
|
| | |
| |
| |
| |
| |
| | |
Leave all other chars prefaced by a backslash alone. Fixes #242.
Not sure why I thought that I needed to add another backslash.
Thanks for the report and the test case @mhubig.
|
| | |
| |
| |
| |
| | |
This mostly revolves around old APIs for ElementTree, but includes a few
others as well. Fixes #254. Thanks for the report.
|
| |\ \
| | |
| | | |
Add feature for emphasizing some lines in a code block.
|
| | | | |
|
| | | | |
|
| | |/
| |
| |
| | |
A code blocked headed by “:::python{1,3}” now emphasizes the first and third lines. With fences enabled, ```python{1,3} has the same effect.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Previously, the code was ignoring whether this was a new term when determining
whether the currect item should be loose or not. Fixes #243. Thanks for the
report @Anomareh.
|
| |
|
|
|
|
|
|
|
| |
Setting output_format must happen after extensions are loaded. Only in that
way can an extension register a serializer so that it will then be available
to be used with the output_format keyword. A test has been added to avoid
this regression from happening again in the future.
Fixes #238, partially reverses commit 41cc055 and provides a better fix for
|
| |
|
|
|
|
|
| |
It is up to the markdown code (and extension authors to make sure tags are
of the correct case (there may be cases were an extension might need to
mix cases - which should be preserved). Fixes #237. Thanks for the report
@eichin.
|
