| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
support.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fixes #195. This was getting missed because the HeadrerId extension's
reset method was resetting the IDs to a list. However, some third party
extensions may want to call the unique function and it should work as
documented. Interestingly, the TOC extension was using it and passing in
a list as well. All fixed now. Also added a test of the `unique` function
directly so we shouldn't repeat this in the future.
|
| | |
|
| |
|
|
|
|
| |
This appears to have recently been broken with the fixes in #191.
This time I've added tests to prevent future breakage and added
documentation to explain the behavior.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes #148. The "force_linenos" config setting of the CodeHilite extension has been
marked as Pending Deprecation and a new setting "linenums" has been added to
replace it. See documentation for the [CodeHilite Extension] for an explaination
of the new "linenums" setting. The new setting will honor the old "force_linenos"
if it is set, but it will raise a PendingDeprecationWarning and will likely be
removed in a future version of Python-Markdown.
[CodeHilite Extension]: extensions/codehilite.html
|
| |
|
|
|
| |
If an adminition title is capitalized, the html class on the
div should still be lowercased.
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
docs/extensions/index.txt
tests/extensions/test.cfg
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Partial fix for #183. This has the same effect on empty lines in code blocks
as not using the html processor at all (which was eating some of the missing
newlines as reported in issue #183).
By doing `rsplit('\n\n')` the third newline (in each set of three) always ends
up at the end of a block, rather than the begining - which it less of an issue
for the html processor.
Also updated tests to indicate final intended output, although they do not fully
pass yet.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Partial fix for #183. By preserving tabs at the start of empty lines in
code blocks, the parser will retain those empty lines. Still does not work
consistantly if the tab is missing!? Not sure why.
Also added tests.
|
| | |
| |
| |
| |
| |
| | |
Fixes #177. When using both extensions, breaks (`<br>`) must have a linebreak (`\n`) after them before attr_list is run. This patch reorders the treeprocessors so that happens ('attr_list' runs after 'prettify' not before).
Also had to alter headerid extension so it runs after 'prettify' or it would run before 'attr_list' if loaded before 'attr_list' by user.
|
| | |
| |
| |
| | |
Fixes #171. While that report provided an example of an unordered list item that started with a colon, any block that starts with a colon and has no siblings before it (paragraph as begining if document, list item, etc) all exhibit this same behavior. Following PHP Markdown Extra's lead, these are not definition items as they have no term before them.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Without this, all SyntaxTests would fail from a git checkout on Windows.
On other systems, it should have no effect.
|
