| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
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.
|
| |/ / |
|
| |/ |
|
| | |
|
| |\
| |
| | |
Enable anchorlinks in Python-Markdown documentation
|
| | | |
|
| | |
| |
| |
| | |
and use it in our docs
|
| | |
| |
| |
| | |
and use it in all extension that need parsing bool config values.
|
| |/
|
| |
spelling.
|
| |
|
|
| |
Happens on pip install with Python 3.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
| |
implemenation -> implementation
|
| |
|
|
|
| |
Not sure why I was using global variables here. Anyway. Fixed now.
Thanks to Andrew for pointing it out.
|
| |
|
|
|
| |
Since adding the new smarty extension, the nex release it more than just a
bugfix release.
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
A list item with a nested list complicates were the attr_list can be.
Fixes #218. Thanks for the report @jpzimmer.
|
| |
|
|
| |
didn't notice the tests were failing for this before.
|
| |
|
|
|
|
|
|
| |
Just set each abreviation as an AtomicString. Given the nature of
abbreviations, they are not likely to ever contain any other markup
anyway. Also added a test.
Fixes #224. Thanks for the report @JakeChampion.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I've added iteritems_compat function in one of my previous pull
requests, which was failing with:
./markdown/odict.py:106: undefined name 'iteritems_compat'
This commit drops usage of that function.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #204. This was a real pain to debug. But I think the problem stemmed
from the fact that the footnote extension inserted a etree link into the
footnotes last p element. Then when inline patterns are run, the inline code
in that p element is processed. Normally, code would be the first child found,
but with the pre-existing link, that wasn't the case and the parser took a
slightly differant path which would never be encountered in any other
situation. It was this slightly differant path that made the lose of the
AtomicString status of the inline code matter.
Since any AtomicString (including inline code) doesn't need to be run though
hanldeAttributes anyway, we can just skip over it and preserve the
AtomicString. Whew!
|
| |
|
|
|
|
| |
The lead comment in blockprocessors.py should really be a docstring for
consistency with other files. Fix this with the other part of
@Arfrever's patch for issue #203.
|
| |
|
|
|
|
|
|
|
| |
A `from __future__ import ...` statement must go after any docstrings;
since putting them before the docstring means the docstring loses its
magic and just becomes a string literal. That then causes a syntax
error if there are further future statements after the false docstring.
This fixes issue #203, using the patch provided by @Arfrever.
|
| | |
|
| |
|
| |
CodeHilite: linenos is replaced by linenums
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The most notable changes are the use of unicode_literals
and absolute_imports. Actually, absolute_imports was the
biggest deal as it gives us relative imports. For the first
time extensions import markdown relative to themselves.
This allows other packages to embed the markdown lib in a
subdir of their project and still be able to use our
extensions.
|
| | |
| |
| |
| |
| |
| | |
As we no longer support older python versions, importing
ElementTree is much simpler. The documented way for
extensions to use etree still remains the same.
|
| | | |
|
