| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
| |
Fixes #343. Thanks for the report @AlexJF.
|
| |
|
|
|
|
| |
The new option parser assumes bool values if the default is bool or
None. As the "title" option is not a bool value, it should default to an
empty string rather than None. Fixes #347.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
'https://pythonhosted.org/Markdown/'. The former redirects to the latter anyway. Might as well point to the actual destination.
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
| |\
| |
| | |
Python 3.4 and fixes for doctests
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| | |
Make smarty extension work together with attr_list
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Simplified, unified style, added some undocumented options.
NOTE: Footnotes/UNIQUE_IDS stays mostly undocumented
|
| |
|
|
|
|
|
|
| |
The previous problem happened because canonicalize() removed the
space from closeClass regexp.
Instead of fixing the function, get rid of it completely. It should
also make module load a bit faster.
|
| | |
|
| |\
| |
| | |
tables and attr_list compatibility
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
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.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
and use it in our docs
|
| |
|
|
| |
and use it in all extension that need parsing bool config values.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Not sure why I was using global variables here. Anyway. Fixed now.
Thanks to Andrew for pointing it out.
|
| |
|
|
| |
It was previously marked pendingdeprecation in v2.3. Now deprecated.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Like headers (h1-6) dt's can only be on one line, so we need to use
the header regex on dt's. This was implemented after considering a recent
[discussion](http://six.pairlist.net/pipermail/markdown-discuss/2013-July/002859.html)
on the markdown mailing list. Prior to that discussion, I never considered
that it was impossable to set block level attrs on dt's. Now it is.
|
| |
|
|
|
|
|
|
|
|
| |
A header can be only one line - so unlike other block level elements, a
attr_list must be at th eend of the line. To disingush it from an inline
attr_list on the last child in a header, we must require at least one
space before th eblock-level attrt_list.
Always intended it to work that way. Not sure how I missed that before.
At least we're testing for it now.
|
| |
|
|
|
|
|
|
|
|
| |
Not sure how I missed that when committing ea4af0d. Also as a side-effect,
this fixes #230 - which brought my previous oversight to my attention.
Thanks for the report @divisoryang.
Also added some tests - including tests of list items without attr_lists.
Sometimes I forget to test markup that does not use an extension when an
extension is enabled. That's what resulted in #230 being reported.
|
